Retry on concurrency failure in TenantProviderBlobStore.UpdateTenantAsync

The `UpdateTenantAsync` method performs a read-modify-write of a tenant—you pass it the tenant ID, and a description of the properties to add, set, and/or remove.

It uses optimistic concurrency, using ETags to detect conflicts. When a conflict occurs, it throws a `TenantConflictException`. This is somewhat unfair because the problem is not the caller's fault. The caller does not pass in an ETag; the point of how this API is designed is that it permits selective editing of particular properties, and it is (or at least should be) OK if other code wants to modify other properties of the same tenant at the same time. In the event of a conflict error, this code could just retry starting again from the read. Currently it does not.