Vera/ENG-401 Remove anyhow

[organizedgrime]

Description

Removed anyhow from error handling responsibilities, removed entirely from dependencies as well. When it is referenced below, it is actually referring to a Box<dyn std::error::Error>. The hole left by the removal of anyhow from this project was vast. In its place, many more nuanced error types needed to be created.

• Refactored ClientError -> ApiError
  • This can have a TombCryptError for dealing with cryptographic information for the api
  • This can have a url::ParseError for dealing with endpoints
  • This can have many kinds of reqwest::Error for various network failings
  • This can conditionally have a FilesystemError as described below if the #[cfg(test)] and #[cfg(feature = "integration-tests")] conditionals are met. This is because api integration tests rely on performing filesystem operations as a frame of reference, but we dont want this included in the compilation case where it is unneeded.
• Implemented CarError
  • This can have an std::io::Error
  • This can have a UtilityError for varint functionality in utils module
  • This can have a cid::error::Error for Cid parsing
• Implemented BlockStoreError
  • This can have a CarError for Car based blockstores
  • This can have an anyhow::Error marked as a wnfs error (wnfs::common::BlockStore trait still relies on anyhow)
• Implemented SharingError for manager / mapper / sharing functionality
  • This can have a TombCryptError, as many functions require tomb_crypt functionality
• Implemented FilesystemError for FsMetadata and related serialization
  • This can have a SharingError for sharing
  • This can have a BlockStoreError, as BlockStore operations required to operate over FsMetadata and serializer
  • This can have a anyhow::Error internal to it marked as a wnfs error (Additional wnfs functionality outside of BlockStore such as put_serializable also relies on anyhow)
• Implemented NativeError for CLI and Native library including Syncing
  • This can have a TombCryptError for loading local configuration keys
  • This can have a FilesystemError for operating on a FsMetadata Filesystem while performing operations such as prepare and restore
  • This can have a ApiError for syncing with remote endpoints
  • This can have a std::io::Error for on disk file operations
• Implemented UtilityError for miscellaneous Utilities and testing that utilizes the testing utilities contained therein
  • This can have a unsigned_varint::decode::Error for varint decoding
  • This can have a std::io::Error for various simple file utilities
  • This can have a std::string::FromUtf8Error for parsing representing bytes as strings in the compute_directory_size utility
  • Can conditionally contain a NativeError if the #[cfg(test)] and #[cfg(not(target_arch = "wasm32"))] conditionals are met, as some of these testing utilities also require Native functionality, but those should not be compiled for wasm or when we are not testing.
• In each of these types are some From impls which minimize the need for using .map_err directly and maintain code cleanliness throughout the project.

Link to issue

https://linear.app/banyan/issue/ENG-401/remove-anyhow

Type of change

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

[linear[bot]]

ENG-401 Remove anyhow

This is part of the tech debt clean up in Tomb. This shouldn't be done until after [ENG-393](https://linear.app/banyan/issue/ENG-393/convert-tomb-from-a-workspace-repo) has been merged. This will be another round of sweeping changes and the two should exist separately in different PRs. In general anyhow is only intended to be used by final binaries not by libraries. We have to deal with WNFS using it against its intended purpose but that doesn't mean we should be. If you receive an error from WNFS it should be treated as a `` Box `` not anything related to anyhow. We should switch to using our own narrow Error types based on \`thiserror\` crate as implemented in the cloud services. I'd recommend reading through [this blog post](https://www.lpalmieri.com/posts/error-handling-rust/) that generally lines up with the goal here. The examples that they go through are for a webserver and they do eventually end up on anyhow, but tomb is not that webserver. We want to be able to programmatically handle different types of errors, log and manipulate them in different ways based on the failure mode.