AzureBlobStorage Etag bug?

[OracPrime]

#3516 is related to this.

In the AzureBlobStorage, there is some inconsitency with Etags. In the WriteStateAsync, the BlobRequestConditions are set to this
new BlobRequestConditions { IfMatch = grainState.ETag != null ? new ETag(grainState.ETag) : (ETag?)null },
which I believe is correct (if Etag on what we're writing is null, don't have to match, overwrite anyway).

However in ClearStateAsync the code is this:
blob.DeleteIfExistsAsync(DeleteSnapshotsOption.None, conditions: new BlobRequestConditions { IfMatch = new ETag(grainState.ETag) })
which fails with a BlobRequestConditions not met exception. I believe the condition should match that in Write.

If @ReubenBond concurs, happy to submit a PR (which would also correct a copy and paste error in some of the logging)

[ReubenBond]

Enough people have been tripped up by this that I think some change needs to happen.

What you're suggesting sounds good to me.

The code for WriteStateAsync does not look correct, though. I believe that if ETag is null, we should set IfNoneMatch instead of IfMatch, like so: new BlobRequestConditions { IfNoneMatch = new ETag(Constants.Wildcard) } } - that will prevent overwrites and maintain consistency in the case where two writers race to create a new blob. With the existing condition, both writers could "succeed", but the later one would clobber the earlier one's write without observing it (i.e, without acknowledging that it's been observed by specifying its etag), so it would be a lost write.

The Azure Storage SDK source code uses that same condition when overwrite is false in this method: https://github.com/Azure/azure-sdk-for-net/blob/e2fad94b95fa2a27a73af758e4e2c39b724c5949/sdk/storage/Azure.Storage.Blobs/src/BlockBlobClient.cs#L2235

[ReubenBond]

Fixed by #7187