[Task] Design and implement a `StorageError`

[PhilippGackstatter]

Description

Design and implement a StorageError that is returned from all Storage methods as Result<T, StorageError>.

For the design, we could take inspiration from serde::de::Error and how it handles custom errors.

We should consider providing some common variants that all implementations likely need:

#[derive(Debug, thiserror::Error)]
pub enum StorageError {
  #[error("requested operation `{0}` is not supported")]
  NotSupported(String),
  #[error("key at location `{0}` was not found")]
  KeyNotFound(String),
  #[error("DID `{0}` was not found")]
  DIDNotFound(String),
  #[error("TODO")]
  Custom(#[source] Box<dyn std::error::Error>)
}

Using Box<dyn std::error::Error> allows a caller to downcast to a concrete error type in case they want to handle errors from a specific implementation.

Motivation

The Storage trait currently uses identity_account_storage::error::Result in its return type, which means the Account error type needs to accommodate the possible storage error from both MemStore and Stronghold, as well as Wasm-specific variant such as identity_account_storage::error::Error::{SerializationError,JsError}. A dedicated StorageError allows for independent error types for our two implementations, as well as external implementations, and without polluting the existing error.

Resources

https://github.com/iotaledger/identity.rs/pull/597#discussion_r812013066

To-do list

Create a task-specific to-do list. Please link PRs that match the To-do list item behind the item after it has been submitted.

• [ ] Introduce a separate MemStoreError that contains the specific errors from the account Error type that only the MemStore needs.
  • [ ] We can take this opportunity to use parking_lot::RwLock instead of std::sync::RwLock and get rid of the SharedReadPoisoned and SharedWritePoisoned error variants.
• [ ] Design & implement the StorageError.

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• [ ] The feature or fix is implemented in Rust and across all bindings whereas possible.
• [ ] The feature or fix has sufficient testing coverage
• [ ] All tests and examples build and run locally as expected
• [ ] Every piece of code has been document according to the documentation guidelines.
• [ ] If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
• [ ] If the feature is not currently documented, a documentation task Issue has been opened to address this.