Make GoogleCloudStorageRetryingInputStream request same generation on resume

[nicktindall]

When we resume a download due to an IOException, we now specify the generation of the object that we were originally downloading in the request so that we can detect if the object changed.

Some decisions that were made

• When resuming we send generation parameter rather than ifGenerationMatch. The former requests a specific generation where the latter requests the latest generation and triggers an error if its not the one specified. This distinction is only important if the bucket we're fetching from has object versioning enabled. If the object is overwritten and object versioning is enabled, resume with generation specified will succeed because the prior version will still be available, but resume with ifGenerationMatch specified would fail because the latest version is no longer the one we were downloading.
  • This is similar to the behaviour of the SDK in their own resumable channels
• We ignore updates to metadata. We specify the generation, which is only bumped when the object contents are updated. If someone updates the metadata that shouldn't break a resume IMO. We could implement this behaviour by using ifMetagenerationMatch or Etags instead, but I don't think we want that.

Closes ES-11432

I marked this PR as "non-issue" because currently we never update objects with different contents. This is just future proofing.

[elasticsearchmachine]

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

[elasticsearchmachine]

Hi @nicktindall, I've created a changelog YAML for you.

[JeremyDahlgren]

Looks good, I just had the one question about the assertion in parseGenerationHeader(), the rest were a few small nits. Might be good to get a look from other folks with GCS code experience though.

[JeremyDahlgren]

LGTM