Add BlockBlobDatabase as TES database option

[MattMcL4475]

This implementation can be used to store TesTasks in Azure Storage instead of PostgreSQL, and reduces Azure resource count and cost (#226 ).

Features

• Cheap - likely the cheapest possible way to store tasks
• Unlimited scale - supports an unlimited number of TES tasks since the number of blobs in an Azure Storage account is unlimited
• Simple - uses the existing default storage account, and doesn't require an additional Azure resource (such as PostgreSQL, Cosmos DB, etc.).
• Reasonable and consistent performance
• Easy to manually view/edit existing tasks via Azure Portal and Azure Storage tools
• Easy integration by using existing Azure Storage SDKs

Implementation notes

• All TesTasks are stored as JSON files as individual Azure Block Blobs
• The blob name is prefixed with whether it's active or not active (a or z respectively), to facilitate fast query by state via the List Blobs operation:

a/0fb0858a-3166-4a22-85b6-4337df2f53c5.json
z/0fb0858a-3166-4a22-85b6-4337df2f53c5.json

Current limitations

• Doesn't support querying tasks by anything other than whether they are active or not, which is fine for TES as is, with the exception of:
• No support for TES spec's ListTasks by name_prefix since this would require downloading every single blob to get the name, or, an alternative implementation (one idea would be to store a separate blob that has all name+id tuples (which could result in contention issues for create/update/delete since a lease would need to be held), OR, to store 2 blobs for every TesTask - one for the existing TesTask, and another that's empty but has a blob name that is the TES task name with special characters encoded and the ID as the suffix, which would enable fast query by List Blobs operation, then extract the IDs from the name and then download by ID as the current LIST implementation does)

[giventocode]

Hmm... I think this retry policy could lead to data loss. Two requests roughly at the same time hit this method, the first fails and the second succeeds (we want the second one to win), the first request will go in retry loop that could overwrite the latest data.

As an alternative you can consider an optimistic concurrency approach for the update, where you check if an item has changed since you last read it - storage supports this via headers, and etags. And for the create scenario, you turn overwrite off, to avoid any race condition.