Proposal: Remote state store for Azure Blob Storage

[jjcollinge]

The current backend options (app.pulumi, local and enterprise) may not be suitable for all potential users. Some users will not require the value-added services available via the Pulumi backend and will be ok with basic blob storage. I took a quick look through the codebase and think the least intrusive way to extend the current backends would be to define new URL patterns for each provider i.e.
azure://storage-account-name. This can then be mapped to the storage account key as the access token in the credentials.json - this will be sufficient to leverage the azblob package to create a client and then we should be able to write a backend implementation for Azure Blob Storage. This pattern could then be used to add other providers such as aws://.... I have some time coming up at the start of October where I can try and implement an MVP for this if you agree this is a reasonable approach. Alternatively, if you have any existing thoughts or WIP that you could share then I might be able to pick that up instead.

EDIT: Another option - instead of writing a full backend for each blob storage, would be to extract a simple CRUD interface out of the existing filestate backend and allow switching in a reader/writer that can talk to different blob providers.

[lukehoban]

@jjcollinge This sounds like a good approach - and the URL scheme design was intended to support this sort of extension. We don't have any existing WIP on this yet, so happy for you to submit a PR for this!

[mikhailshilkov]

It looks like this should be closed as implemented by #2455

> pulumi login --help
...
Additionally, you may leverage supported object storage backends from one of the cloud 
providers to manage the state independent of the service. For instance,
...
Azure Blob:
    $ pulumi login azblob://my-pulumi-state-bucket
...