Extract solana-feature crate

[kevinheavey]

Problem

solana_program::feature imposes a solana_program dep on solana_rpc_client

Summary of Changes

• Move to its own crate and re-export with deprecation
• Make serde and bincode optional in the new crate

[joncinque]

Since this is the feature gate program's equivalent of an "interface" crate, can we call it solana-feature-gate-interface? We can eventually move this into https://github.com/solana-program/feature-gate/, but I don't think it's necessary just yet.

cc @buffalojoec does that sound ok?

Otherwise, it looks good to me!

[joncinque]

Looks good to me! @yihau can you accept solana-feature-gate-interface?

[buffalojoec]

Since this is the feature gate program's equivalent of an "interface" crate, can we call it solana-feature-gate-interface? We can eventually move this into https://github.com/solana-program/feature-gate/, but I don't think it's necessary just yet.

cc @buffalojoec does that sound ok?

Yeah I don't want to block SDK breakup work, so this is okay for now, but I do think most (if not all) of this should go in the program's client, so maybe we should consider deprecating it? We can publish the Rust client anytime.

[joncinque]

Since the feature gate program depends on these types, it would create a sort of circular dependency for the program. Program depends on client, and client is generated from program.

We've opted for creating "interface" crates which just contain state / instruction / error types, so that IDLs can be generated. So I'd actually want to move more stuff into the interface crate from the program!