This is a sort of MVP 1 step before adding in delegated tx toml support. This pr adds in direct, non delegated, tx support from a toml as such (also note that the delgated toml will be slightly different and include an expiration timestamp):

[sender]
source_private_key_path = "/Users/phil/Desktop/peggyJV/ocular/ocular/src/chain/client/test_dir/Zeus.pem"

[[transactions]]
name = "Dionysus"
destination_account = "somm17ekgjxvavx94mpk7cxudkc9lwcc5x2snlq9d3d"
amount = 50
denom = "usomm"
gas_fee= 10000
gas_limit = 100000
timeout_height = 9001
memo = "Don't spend it all in one place."

[[transactions]]
name = "Silenus"
destination_account = "somm18263d6928pzud0wj7mtk7arvfx976tkqsv6sxd"
amount = 500
denom = "usomm"
gas_fee= 10000
gas_limit = 100000
timeout_height = 9001
memo = "Lorem Ipsum"

Closes #13 and #15

This PR does a number of things:

1. Restructures the registry module such that it is no longer under chain, and moves the asset objects into into their own registry::assets submodule.
2. Switches to using raw.githubusercontent.com file endpoints for single-file retrieval such as for get_chain() and get_assets(). The octocrab crate is still used for getting the list of IBC path and chain names.
3. Adds a registry-cache feature which houses the RegistryCache type.
4. Adds IBC path retrieval methods requested by the Hermes relayer team in #13 and #15. Both the registry module itself and the cache have a get_path(chain_a, chain_b) method. The former will make a network call to the chain registry github repo, the latter will use the already-cached data. This allows a path to be queried pairwise even without the cache feature enabled. To retrieve all paths with a given tag, the cache must be used.

Implement the query logic that exists in lens and also expose the different modules' query clients in case users want more fine-tuned queries (with pagination for example)

• [x] Bank query client and queries
• [x] Other module query clients
• [x] Test coverage

• Hides AccountInfo fields behind methods
• Decouples AccountInfo from a specific prefix. address() and id() will derive the respective values on demand given a prefix &str.
• Puts an AccountInfo's private key behind an Arc<T> so that it can be Clone. This makes the type much more ergonomic.
• Adds TryFrom<SigningKey> and TryFrom<Arc<SigningKey>> impl constructors for AccountInfo. Importantly, it checks that an AccountId can be derived from the associated public key and returns an error otherwise. This allows us to assert that the AccountId derivations will not error and therefore don't need to return a Result. EDIT: changed to From<T>

Example

// Get an account's address from a key in a keystore
let account = keystore.get_account("my_account")?;
let address = account.address("cosmos")?;

// Create a new private key and derive the account
let sender_mnemonic = keyring
    .create_cosmos_key("my_new_account", "", true)
    .unwrap();
let seed = mnemonic.to_seed("");
let private_key: SigningKey = SigningKey::from_bytes(
    &bip32::XPrv::derive_from_path(seed, path)
        .expect("Could not create key.")
        .private_key()
        .to_bytes() as &[u8],
)
.unwrap();
let account = AccountInfo::from(private_key);

EDIT: examples after updates

• Adds in MsgExec, MsgRevoke, and MsgGrant authz functionality
• Adds in basic FeeGrant functionality
• Adds in AuthZ grant query functionality
• Implements toml reading & parsing for delegate tx workflows, e.g.:

[sender]
grantee_private_key_path = "/Users/phil/Desktop/peggyJV/ocular/test_dir/Zeus.pem"
grantee_account_number = 1
grantee_sequence_number = 0
granter_account = "somm1wdvjp39hg9ct2wkpslyfvnk0r7tup27jsd6j0a"
denom = "usomm"
gas_fee = 50000
gas_limit = 100000
timeout_height = 9001
memo = "Delegation memo"

[[transaction]]
name = "Dionysus"
destination_account = "somm1jlfkfh40pky9l2e38njcl58hampjha4852w6w4"
amount = 50

[[transaction]]
name = "Silenus"
destination_account = "somm1pk8l5tj50qqcuk2u0weu0smdmqpjvdg2k77krf"
amount = 500

• Adds in tx logging e.g. 1649286032871346000.txt

• Remove MsgDelegate & MsgUndelegate functionality + testing due to signing bugs (didn't want to leave broken unused code, will bring back later in fixed state)

There should be some sensible harmony of key/account management. Accounts will be used for transactions and the lower-level key management for just that.

Accounts are just abstractions on top of keys; therefore "creating" an account is just an abstraction of generating and saving a new private key, or deriving a new address from an existing public key. Account should be able to yield addresses with any prefix provided, with a go-to method defaulting to "cosmos".

Need to look into supporting module accounts as well.

Major rework. Chose to do it because scope creeped enough that we weren't going to get to a release quickly, and several features belong in their own crates. Will release alpha versions of 1.0.0 until all core SDK module query and transaction types are covered. Registry chain interaction can be added as a feature after. Airdropping + registry interaction should be their own crates, and possible the Keyring too.

• [x] Integration tests for full airdropping flow, delegated and undelegated
• [x] Integration tests for individual methods where relevant
• [x] Unit tests of relevant methods
• [x] Mainnet test with real funds

• Broke queries in query.rs into their own sub-modules based on Cosmos module
• Broke tx methods into sub-modules under a tx module based on Cosmos module
• Condensed query client construction to a factory and QueryClient trait

Before release?:

• [ ] Reliable gRPC endpoint selection when using automatic client construction
• [X] Easy Account reference construction from key
• [x] Auth, Authz and Bank module txs and queries
• [X] Automatic and Manual client construction paths
• [X] Airdrop functionality
  • [x] Rigorous testing
• [x] Unit and integration test coverage

Changes the constructors to use create() for a default chain registry generated client, and new for manual construction. Also adds a ChainClientBuilder for a streamlined approach to generated a client from the registry but setting certain values manually.

I had to kneecap the health checks during client construction. @philipjames44 I'm pretty sure that health check stuff overlaps with some work you're doing so we can wait to merge this until your work is done.

Closes #49

We need either a feature or separate ocular crate in the workspace for hosting a cache of the chain registry with a RESTful API for ocular to query chain and IBC path information. This should be optional as a user may opt to manually configure their chain client and/or read in IBC path data some other way.

Try every chain and asset chain json in cosmos/chain-registry so that each version of ocular that is deployed is guaranteed to function correctly when released.