feat!: merge @web3-storage/access-api into @web3-storage/upload-api

[travis]

As part of the transition from D1 to Dynamo for delegation and provision storage, move service providers from @web3-storage/access-api to @web3-storage/upload-api.

This change decouples this entire repository from any particular storage implementation and should make it easier for third parties to create w3up-compatible storage services. We now expose 2 storage interfaces - DelegationsStorage and ProvisionsStorage - and an email provider interface (right now simply called Email) that implementors like our very own w3infra need to implement. A prototype implementation of these interfaces can be found in storacha/w3infra#194 - feedback on that PR was the basis for some of the public interface changes in this PR.

I've also taken this opportunity to drop support for the voucher protocol and stop using the spaces table which appears to only support that. I've also dropped the accounts table since it didn't seem to be adding anything - the one query we made to it returned the account DID that we used to query the table. Once we have a clearer picture of what information we want to store in an account we can bring that back if that makes sense.

Important notes for reviewers:

• There are definitely some awkward interfaces hanging around after merging these two codebases - please feel free to call them out, and I'll either fix them now or file some fast follow issues for more time-intensive refactors.
• I've deleted access-api primarily because it makes the PR much more readable. I'm open to removing it with this PR, but also open to keeping it in - if we decide to keep it for now, I'll restore it just before merging.
• @Gozala has identified a number of improvements to the interfaces and underlying design - some of them I hope to incorporate into this round of work and may result in some (hopefully small) changes to this PR, some of which I think make sense for future work
• we should rename upload-api. should we rename upload-api? probably? now or later? I don't have super strong feelings, but we should probably do this soonish?

TODO

• finish feat!: fold access-api into upload-api w3infra#194
• incorporate @Gozala's feedback about interfaces from feat!: fold access-api into upload-api w3infra#194
• move Email implementation to w3infra
• port relevant tests from access-api to upload-api

[travis]

woo hoo! updated per all of these comments.

Only thing I would like to be addressed is the fact that we simply return customer DID from the customer/has without any checks.

I've done this in 4287e85, but it's induced a bit of a change that broke tests in a way that I fixed in 35cff74

The idea behind the change is that we shouldn't consider a user a "customer" until we've provisioned storage for them. The test I updated in 35cff74 would verify that after a user did an access/authorize we'd get a customer record back when we invoked customer/get with their DID.

This is tricky the way things are currently implemented because we don't actually save a "subscription" record until we allocate that customer storage, and that's what we currently use to track customers.

We could introduce a new "customers" table and add a record to it when we invoke access/authorize but that's actually not my preference - I'd like to avoid tracking information about customers unless we have a relationship with them that means we'll be storing non-delegation data for them, and I like how the current system operates in that regard.

@Gozala what do you think? Happy to jump on a quick call tomorrow to chat more if that'd be helpful!

[travis]

Also @Gozala just want to make sure that 4287e85 addressed the issue you mentioned above with customer/get - if it does could you hit the approve button?