Git pack-objects ignores CRC32 when writing to stdout

In the context of !1244 (closed), the following is worth noting:

https://github.com/git/git/blob/v2.22.0/builtin/pack-objects.c#L2614-L2622

	 * If we're locally repacking then we need to be doubly careful
	 * from now on in order to make sure no stealth corruption gets
	 * propagated to the new pack.  Clients receiving streamed packs
	 * should validate everything they get anyway so no need to incur
	 * the additional cost here in that case.

Git packfile indexes contain CRC32 checksums of individual objects. These are used, instead of fully calculating the object SHA, when reusing pieces of an existing packfile. What we see at the line I linked above is that when git pack-objects thinks it's serving a git fetch response, if skips the CRC32 check, because the client will notice immediately if data gets corrupted. This is because the response is a .pack without a .idx, and the client will compute the .idx itself. That implies calculating the SHA1 of each object in the pack, which in turn implies that corruption would get detected.

In the context of !1244 (closed), where we use git pack-objects to create repo snapshots that we then store in object storage, we have a problem: we are not creating a .idx file, so if there is data corruption, we won't find out. Not until much later.

One thing we can do about this is that before we upload to object storage, we create both a .pack and a .idx, and we upload them together. The .idx is then more or less proof that the .pack contains the objects we want. This would make snapshots slower though, because we must first write all the snapshot data to local disk before we can begin uploading.

An alternative would be to modify the behavior of git pack-objects, so that it becomes possible to have the CRC32 checks in our particular situation.

A third alternative would be to accept the risk, and have two kinds of snapshots: "unverified" (.pack only) and "verified" (.pack plus .idx). Also consider that there is value in pre-computing .idx files because it speeds up the restore process.