bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows

[sb]

This happens for me on emacs 26.3, but has happened ever since I first
tried to use gnus-cloud in 2016, so I've never been able to use
gnus-cloud (I've continued to use its predecessor gnus-sync, but with
emacs 27, gnus-sync no longer worked).

When gnus-cloud-upload-all-data is run in gnus on emacs on windows, the
byte count in the sync data chunks is wrong, so that the data is broken
when attemting to sync on a debian machine.

The first chunk has the following header:
(:type :file :file-name "~/.gnus.el" :timestamp "2021-09-19T15:04:33+0200" 
:length 16241)

The byte count here is 16241, but it should have been 15754.

This results in the contents of the score files that follows .gnus.el to
be copied into .gnus.el and the .gnus.el file becomes unparsable.

The difference in length corresponds to the number of lines in .gnus.el,
so I'm guessing it's because the CR in CRLF line endings is stripped
away.

The place where the length is set, is here
  https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n98

I've tried taking the length of the string instead of the size of the
buffer, but the count for .gnus.el still came out as 16241 (so the CR
stripping doesn't take place there).

I've also, as an experiment, replaced insert-file-contents-literally,
with insert-file-contents, and then windows gnus wrote data that
gnus-cloud-download-all-data on debian gnus could read.

But that's probably not a fix, since insert-file-contents-literally is
used intentionally?

This is with
(gnus-cloud-storage-method nil)
which is what I've been using for debugging because attempts to using
base64 with gzip caused error messages of the type "not base64"
(presumably also because the byte count was wrong?).