Use blob ETags in Read/Write/Clear

[ReubenBond]

Currently, the storage provider will overwrite blobs regardless of whether or not the grain is using the latest version of that blob.

This change propagates the blob's ETag between read, write, and clear.

This fixes concurrency bugs which can occur due to temporary silo failure and upgrades, or when blobs are externally modified.

Calls which are made to write a blob with an incorrect ETag will result in Orleans re-reading the state and re-activating the grain.

[ReubenBond]

Note that Orleans' effectively pushes consistency requirements to the storage layer, so this enables optimistic concurrency.

This change aligns the behavior with that of the the built-in Azure Table Storage provider, so there should be no surprises for consumers.

[gabikliot]

BTW, in general, what do people think about this model, that Orleans effectively pushes consistency requirements to the storage layer? Too problematic, you like it, ...?

[ReubenBond]

I like it: pushing consistency requirements down the stack makes sense.

Some get confused about how many activations for a given grain may exist at any point in time, though. It might help if we had a page detailing Orleans' consistency model (& guarantees) in simple terms.

[gabikliot]

Great idea! We will write it next week. We already started clarifying a lot of important internal design decisions here: (https://github.com/dotnet/orleans/wiki/Runtime-Implementation-Details)

[richorama]

sorry, finally got round to merging this and pushing to nuget...

[ReubenBond]

No worries :)