Storage: Use RequestConditions and return exploding responses

[tg-msft]

It's probably best to review this by commit:

• The first commit switches to use Azure.Core's RequestConditions
• The second commit updates all the conditions parameters
• The third commit switches to exploding responses (Fixes [P0] Storage: Update Create/DeleteIfNotExist failure cases #7896, Fixes [P0] Storage: Change File Upload semantics to not overwrite by default #8049, Fixes [P0] Storage: Change Batch Response.Status to 0 #8230)
• The fourth commit re-records tests

[pakrym]

Filed #8292

[seanmcc-msft]

What is an ExplodingResponse?

[tg-msft]

That's an affectionate name for Response<T>s that will throw if you try to access Value. It's the pattern we've settled on for 304s per Azure/azure-sdk#638.

We want to avoid throwing exceptions if we can because they're not great for performance and clutter up logs. If you add an HTTP precondition on a GET/HEAD operation, Storage will return a 304. Instead of throwing, we'll give you back a Response<T> that has a Status == 304 and will still throw if you try to access Response<T>.Value. This gives us the best of both worlds because it'll still throw for customers who don't check, but there's a way for customers who know better to avoid the exception. All other HTTP verbs will return a Status == 412 and we always throw for those.

We just need to be careful in our code that we don't accidentally touch Response<T>.Value if it might explode.

[seanmcc-msft]

Where are these AddConditions() methods used?

[tg-msft]

These are used by the base ToString. Instead of having [BlobRequestConditions:IfMatch=null;IfNoneMatch=null;...] we'll just list the conditions that are actually present so it'll be [BlobRequestConditions:IfMatch=...;LeaseId=...] if you're only using IfMatch/LeaseId.

[annelo-msft]

The wildcard makes the semantics here "update if the blob (however identified from its unique identifier) is not present."
This means it will fail if you try to upload a blob that is the same version as the one you're holding, which technically is not overwriting it. I would have expected IfNoneMatch to take the Etag of the blob, so it would fail if you're trying the update with a different version, which would overwrite existing data. If theses are the semantics the service defines, though, I'm not concerned.

[tg-msft]

Yes, 99% of the time this API is called we won't have an ETag to use. That's part of why we called this overwrite instead of onlyIfUnchanged like you're doing in AppConfig since it's not relative to an existing ETag. Any customer who wants that behavior could the overload that allows them to pass BlobAccessConditions.

[annelo-msft]

LGTM