Use only the client crate for `solana-account-decoder`

[buffalojoec]

Problem

As reported in anza-xyz/agave#265, the entire config program doesn't need to be used in solana-account-decoder.

In the linked PR, one of the main issues with this dependency relationship is the implicit dependency of solana-account-decoder on solana-program-runtime. This is no longer the case since this program is now BPF.

However, it's a very opportune time to end the pattern of using full program crates as APIs, and instead use their client crates.

cc @kevinheavey

[buffalojoec]

Discussion also continued a bit here #1 (comment), where the main point is determining how the necessary functions land in the client.

From @kevinheavey 's list:

• ConfigKeys, which has field serialized using short_vec, which I believe Kinobi does not support
• get_config_data, which is a custom helper function using and relies on short_vec via ConfigKeys
• The ConfigState trait which Kinobi won't generate since I believe it doesn't generate traits
• create_config_account, a helper function that relies on ConfigKeys (and short_vec) to build an AccountSharedData

[buffalojoec]

Sorry for all of the jumping around @kevinheavey, but I wanted to have a designated place to continue this discussion.

If we hoist the instruction builders out of the program crate and into the client, ConfigState can go with them. That just leaves ConfigKeys, which would be generated in the client but needs short_vec support. We can also hoist get_config_data to the client.

@lorisleiva how feasible is it to support short_vec in Kinobi?

[kevinheavey]

One solution is to not autogenerate the Rust client. You already have all the client code anyone needs in the Agave repo and it just needs to be cut and pasted here

[lorisleiva]

Hey @buffalojoec, it shouldn't be too difficult tbh. On the spec side, I just need to add the shortU16 format to the NumberTypeNode. Then it's just the matter of updating the Rust and JS renderers such that they use that new piece of information accordingly. For JS that's super easy as codecs are already ready for this. For Rust, that just mean we'll need to add a dependency to the crate that offers short_vec which may be okay client-side.