fix: Support REST responses with their own ETag field.

[amanda-tarafa]

Unblocks releasing Google.Apis.Contentwarehouse.v1

@jskeet as usual, a commit at a time so that generation changes are clear. I'll probably rebase into a single commit before merging though, the first commit won't even build.

[amanda-tarafa]

Converting to draft, not yet ready for review.

[jskeet]

So if both ETag and ETagValue are sent, presumably we'll end up with

{
  "etag": "value1",
  "ETag": "value2"
}

Is that what the API is expecting?

[amanda-tarafa]

So if both ETag and ETagValue are sent, presumably we'll end up with

{
  "etag": "value1",
  "ETag": "value2"
}

Is that what the API is expecting?

In principle yes, although we've only seen this on a Response with only an "ETag" but not an "etag". But, since the Response is a top level model without an "etag" we generate an ETag property which is the one that clashes with the one that is normally generated from the "ETag".

Happy to chat about this more. I don't think it's too risky, but definetely some.
At the moment this change has no effect except on Content Warehouse V1, I just ran generation for all and there were no changes.

[amanda-tarafa]

Marking as ready for review as everything generated fine locally.

But I'm more than happy to reconsider.

[jskeet]

I'm wondering whether we shouldn't just not autogenerate the existing one - which could be done by changing the situation under which we generate it. Let's chat about it when we're next meeting.

[jskeet]

I'm still nervous about how things will be parsed if we get both "etag" and "ETag" in the response - it would probably be good for us to test that. (Json.NET is case-insensitive by default; I can't remember whether we change that.)

Beyond that, I think we just need to bike-shed on the name. I think "ETagData" might be clearer than "ETagValue", but both are a bit tricky. Alternatively, to avoid any possibility of other collisions, we could just use "ETag_" or "ETag__" in the same way that we escape other things.

[amanda-tarafa]

Yep, I'll add tests for having two etags on the JSON.

Re naming, I actually like the "__" approach better, it doesn't put on the spot about picking a name for the property and the field documentation can give a way better explanation of what it represents than we can ever capture with a name.

I'll make those changes and push shortly.

[amanda-tarafa]

I've changed to use "ETag__" and created googleapis/google-api-dotnet-client#2531 for testing the default JSON serialization behaviour. PTAL.

[jskeet]

Great, thanks - and thanks for the test in the other PR.