New Subxt API to support offline and dynamic values

[jsdw]

Just some thoughts on a new API for subxt to allow constructing and working with values offline, as well as making it easier to plug in dynamic values (or other custom user created values).

The core idea is that we invert things so that instead of starting with an api that lives in generated code, and then building things off that, we build things first (from generated code or using dynamic Values) and then pass the API in to do the leg work (a bit like how in eg sqlx you construct the query and then provide a client to execute it).

The client we pass in can be Offline or Online (Online is a superset of Offline); a call will only require the Offline trait if it doesn't need to do anything online (eg it wants to encode, sign or validate a transaction but doesn't care abotu submitting it).

Here are some rough examples. What do you think?

//// Step 1: Construct a client (offline or online) to use.

// Construct an API client
let api = Client::new()
    .build::<DefaultConfig, PolkadotExtrinsicParams<DefaultConfig>>()
    .await?;

// (this could also be an offline-only client, and internally it uses one.
// if you want to do offline stuff, you need to provide some core details yourself..)
let api = OfflineClient {
    genesis_hash: hash,
    metadata: metadata,
    runtime_version: version
}.build::<DefaultConfig, PolkadotExtrinsicParams<DefaultConfig>>();

// The traits for Offline and OnlineClient might look something like the following..
// if a fn doesn't need to use the RPC API it will accept OfflineClientT.
trait OfflineClientT {
    pub fn encoded(&self) -> Vec<u8> {}
    pub fn signed(&self, signer) -> Vec<u8> {}
    pub fn validate(&self) -> Result<(), ValidationError> {}
}

trait OnlineClientT: OfflineClientT {
    pub fn submit() {}
    pub fn submit_then_watch() {}
}

//// Step 2: Build the data up that you want to submit/work with and then pass the client
//// in to actually take the data and do the work... 

// build transaction data then pass in API, rather than
// building a transaction starting with an API. This allows
// us to construct offline transactions.
let tx = polkadot::tx()
    .balances()
    .transfer(dest, 123_456_789_012_345)
    // pass client in. Needs OnlineClientT.
    .sign_and_submit(&api, &signer).await?;
    .sign_and_submit_then_watch(&api, &signer).await?;
    // eg these only would need OfflineClientT
    .validate(&api)?;
    .call_data(&api)?;
    .signed(&api, &signer)?;

// ..we can also build a dynamic transaction and then pass it
// through the same interface to submit it etc.
let dynamic_tx = subxt::dynamic::tx("balances", "transfer", vec![
    dest_value,
    Value::uint(123_456_789_012_345)
]).sign_and_submit(&api, &signer)?;

// Constants work the same way..
let constant = polkadot::constants()
    .balances()
    .whatever()
    // takes OfflineClientT
    .fetch(&api)?;
    .fetch_bytes(&api)?;
    .fetch_dynamic(&api)?;

// .. and we can dynamically create the accessor too.
let dynamic_constant = subxt::dynamic::constant("balances", "something")
    // Same code as above ideally, but no fetch.
    .fetch_dynamic(&api)?;

// Storage, too...
let storage = polkadot::storage()
    .balances()
    .foo(input1, input2)
    .fetch(&api)
    .await?;

let dynamic_storage = subxt::dynamic::storage("balances", "foo", vec![
    input11_value,
    input2_value
]).fetch_dynamic(&api).await?;

// Events don't have any accessor bits; we can attach the event APIs onto the
// OnlineClientT so it's similar to now (except the code doesn't need to be in
// the codegen stuff since there is no more to_runtime_api lark).
api.events().subscribe()...