Allow dispatch_query to run directly against storage

[preston-evans98]

Background

Currently, the dispatch_query method from the DispatchQuery trait in sov-modules-api takes a mutable reference to a WorkingSet as an argument. This is not very ergonomic for queriers, who have to create a new (empty) WorkingSet wrapping a storage instance and then run their queries against it.

Suggested Change

Create a new trait for queryable storage, and then have WorkingSet and ProverStorage implement it. Use this trait in DispatchQuery instead of a concrete WorkingSet

pub trait DispatchQuery {
    type Context: Context;
    type Decodable;

    /// Decode serialized query message
    fn decode_query(serialized_message: &[u8]) -> Result<Self::Decodable, std::io::Error>;

    /// Dispatches a query message to the appropriate module.
    fn dispatch_query<Q: QueryableStorage>(
        &self,
        message: Self::Decodable,
        working_set: Q,
    ) -> QueryResponse;
}

[bkolad]

There is also another design choice we can consider:

1. We define query as:

   pub trait DispatchQuery {
   type Context: Context;
   type Decodable;
   
   /// Decode serialized query message
   fn decode_query(serialized_message: &[u8]) -> Result<Self::Decodable, std::io::Error>;
   
   /// Dispatches a query message to the appropriate module.
   fn dispatch_query<(
       &self,
       message: Self::Decodable,
       storage: &C::Storage,
   ) -> QueryResponse;
   }

2. We change the way how we get data: Instead of:

   pub fn query_value(&self, working_set: &mut WorkingSet<C::Storage>) -> Response {
       Response {
           value: self.value.get(working_set),
       }
   }

   We do:

 pub fn query_value(&self, storage: &C::Storage) -> Response {
        Response {
            value: storage.get(&self.value);  <- this has changed
        }
    }

And to be consistent in call, we change:

 let admin = self.admin.get_or_err(working_set)?;

to

 let admin = working_set.get_or_err(&self.admin)?;

Advantages:

• less plumbing as we use Storage & WorkingSet without introducing the additional trait
• query() and call() methods can accept different arguments (Storage or WorkingSet); this will enable us to add some methods to WorkingSet and use these methods in calls without affecting query.

Disadvantages: Maybe

 let admin = self.admin.get_or_err(working_set)?;

is more common/intuitional than

 let admin = working_set.get_or_err(&self.admin)?;

[preston-evans98]

I thought about this, but I think it will be important to be able to run queries against a working set. For example, when you run eth_call geth conceptually creates a new working set, executes against it, then runs your query against the working set and drops the set before returning.