Extract rpc-filter crate

[kevinheavey]

Problem

solana-rpc-client-api is too big and filter.rs is easy to pull out

Summary of Changes

pull it out and re-export with a deprecation notice

[mergify]

If this PR represents a change to the public RPC API:

1. Make sure it includes a complementary update to rpc-client/ (example)
2. Open a follow-up PR to update the JavaScript client @solana/web3.js (example)

Thank you for keeping the RPC clients in sync with the server API @kevinheavey.

[CriesofCarrots]

Sorry, I'm going to need more detail on the problem: by what metric is solana-rpc-client-api "too big"?

[kevinheavey]

A release build takes 70 seconds on my machine and pulls in a long list of heavy dependencies that many use cases don't require, such as spl-token-2022, solana-transaction-status, solana-program-runtime, solana-zk-token-sdk and reqwest

[CriesofCarrots]

A release build takes 70 seconds on my machine and pulls in a long list of heavy dependencies that many use cases don't require, such as spl-token-2022, solana-transaction-status, solana-program-runtime, solana-zk-token-sdk and reqwest

Sorry, I think I'm going to need to see the bigger picture before jumping on board with this PR or #2084
It doesn't necessarily make sense to me to make every module in the repo its own crate. When would you use RpcFilterType, for instance, without one of the config types?

[kevinheavey]

Ah the bigger picture is that rpc_client_api::config is also big enough to be more than one crate - it exposes a bunch of structs that 99% of use cases don't need.

But I'd be open to starting by just making a crate that houses both config.rs and filter.rs

[kevinheavey]

Closing in favour of #4038