Vera/ENG-308 Data Restoration

[organizedgrime]

Description

Huge refactor of CLI structure:

• New OmniBucket class now holds two optional fields, one being a LocalBucket and the other being a RemoteBucket.
  • This new struct is used in CLI output as well as important operations
• Bucket Syncing now uses a SyncState enum to assess and articulate the current status of a local and remote bucket in comparison to each other.
• Metadata pushing and pulling is now integrated into this syncing in a context-aware way rather than the previous method which required users to manually push metadata themselves.
• Data reconstruction appears almost entirely functional- there is something wrong with PrivateForest reconstruction that although reproducible is hard to understand as it is not an issue in WASM presently. Currently syncing with Phillip in search of a fix.
• Now using the latest version of tomb-crypt, making this repo home to the necessary WebCrypto helper methods.

Link to issue

https://linear.app/banyan/issue/ENG-308/data-restoration

Type of change

• [x] Bug fix (non-breaking change that fixes an issue)
• [x] New feature (non-breaking change that adds functionality)
• [x] Refactor (non-breaking change that updates existing functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update
• [x] Comments have been added/updated

Test plan

Most of this code is integration based and should not be tested through cargo tests but rather through actually interacting with the tool.

[linear[bot]]

ENG-308 Data Restoration

Tomb cli should be able to get the current metadata from the metadata service for an individual bucket, and begin restoration using that. If it encounters a data block that is not present it should request the storage providers associated with that bucket using the API defined in [ENG-304](https://linear.app/banyan/issue/ENG-304/block-storage-retrieval-staging-service). It should try each of the storage providers returned in the order they were returned to attempt to retrieve the blocks. When multiple blocks are needed it should attempt to continue using the storage provider returned until it encounters a 404 error as most blocks that are part of a restore will most likely be stored together. If a 404 is encountered the next storage provider should be tried. If the [ENG-307](https://linear.app/banyan/issue/ENG-307/metadata-service-block-lookup) API returns a non-200 response the restore should be aborted with an error. If an individual block is not available in all of the returned storage providers, the restore should be aborted with an error.

[sstelfox]

Looks good 👍🏼