Extract solana-nonce crate

[kevinheavey]

Problem

solana_program::nonce imposes a solana_program dependency on solana_svm

Summary of Changes

• Move to its own crate and re-export for backwards compatibility
• Make serde optional in the new crate

This branches off #2969 so that needs to be merged first

[joncinque]

The change looks good as is, while we're here, I'd like to do a little reorg for these files, since I always get lost in them. Could you:

• rename state/mod.rs to versions.rs, remove the re-export from current
• rename state/current.rs to state.rs

This makes some of the re-exports in solana-program a little gnarly, but I hope it'll be clearer at the base crate level. I believe we'll need to:

• re-export solana_nonce::state::State in nonce/mod.rs
• re-export solana_nonce::versions::* and solana_nonce::state as current in nonce/state/mod.rs
• remove nonce/state/current.rs

Or if it's too annoying, I can push those changes to your branch. Let me know!

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.

[joncinque]

Looks good to me! @yihau, please accept ownership of solana-nonce once it's passed

[t-nelson]

is this not missing deprecation warnings for the old locations?

[joncinque]

is this not missing deprecation warnings for the old locations?

Nice catch! Yeah we can add them. Since the deprecation warnings on re-exports don't actually do anything, it's not a big deal if they're missing. It's like forgetting comments.

[febo]

is this not missing deprecation warnings for the old locations?

Nice catch! Yeah we can add them. Since the deprecation warnings on re-exports don't actually do anything, it's not a big deal if they're missing. It's like forgetting comments.

It might be the case that clippy will actually start complaining about having them. 😅

rust-lang/rust#132038

[t-nelson]

is this not missing deprecation warnings for the old locations?

Nice catch! Yeah we can add them. Since the deprecation warnings on re-exports don't actually do anything, it's not a big deal if they're missing. It's like forgetting comments.

yeah i've been thinking that we've been doing this backwards. we should be deprecating the symbols in their original location, then allowing deprecated on the new location/reexport. when we remove the deprecated code, that's when we actually move the symbols.

[kevinheavey]

yeah i've been thinking that we've been doing this backwards. we should be deprecating the symbols in their original location, then allowing deprecated on the new location/reexport. when we remove the deprecated code, that's when we actually move the symbols.

Wouldn't that mean we'd be stuck with solana-program as a dependency everywhere until 3.0?