Create subxt-core crate; a no_std subset of subxt functionality?

[jsdw]

We'd like to make Subxt no_std compatible where possible. However, making parts of subxt support no_std as it stands is a bit tricky, and would lead to a bunch of #[cfg(not(feature = "std"))] type annotations in a bunch of places and a bunch of refactoring needed to break apart the bits that can and can't run on no_std.

As an alternative approach, how about we take the no_std compatible functionality out of Subxt and put it into a subxt-core crate which is no_std compatible and which subxt would then depend on. This would move Subxt more towards being a crate that just pulls together the core logic with the RPC stuff, generated code and higher level interface, allowing users to depend only on the lower level crates that they need instead if needed/preferred (this is in line also with our desub work, which will take out the logic for decoding storage and extrinsics and have Subxt depend on it from elsewhere).

I think we'll need to iterate on what the interface looks like a bit, trying out and refining something as we go.

Some thoughts on what we could put in this crate:

• Functionality for constructing and signing transactions (inc traits so that eg subxt-signer could depend on subxt-core and not subxt when it uses the subxt feature flag).
• Functionality for decoding blocks, extrinsics* and signed extensions.
• Decoding constants
• Decoding storage entries*, and constructing them
• Encoding runtime calls
• (essentially, almost anything that the OfflineClient can do?)
• All of the traits that enable us to encode/decode these things from eg scale_value::Value or codegen or whatever else (subxt can re-export them).

Other thoughts:

• Could rely on subxt-metadata directly to provide the metadata it needs to decode/encode things (assuming that can be made no-std too, which I think should be ok).
• subxt-signer could depend on subxt-core rather than subxt when using the "subxt" feature flag.
• On its own, the interfaces we provide here should be well documented and easy to use; just as important as subxt interfaces.
• The code generated by subxt-codegen could be made no-std and be used in conjunction with subxt-core to give a static interface for doing these things.
• We could re-export subxt-core from subxt as subxt::core, and then eg subxt-macro could possibly end up pointing to subxt::core by default but could also be redirected to point directly at subxt_core?
• Whichever interface we pick here should be nice to use but also integrate easily with subxt without adding inefficiencies like needing to clone metadata lots or whatever. Possibly that will lead to either a more raw function based interface, or one involving more lifetimes so that it's cheap to construct, use and throw away as needed. (I' leaning to something more raw like subxt_core::tx::create_signed_with_nonce(opts); only provide params we need at the time they are needed, unlike Subxt which gets genesis_hash, metadata, runtime_version up front because it's easiest to store/update them in one place, and then doesn't need them for most things).

* The functioanlity for decoding extrinsics and storage values will move out to desub or similar eventually.

These are just initial thoughts; I think we'll need to just try some things out, get feedback early and often, see what we can do or what road bumps we run into, and iterate from there until we have something really nice.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/parity-tech-update-for-february/6630/1

[jsdw]

This crate is now about ready to be published as of #1508, so I'll close this!