Extract decode-error from solana-program

[kevinheavey]

Problem

The DecodeError trait in decode_error.rs gets used all over solana-program, making it hard to move anything out of solana-program.

Summary of Changes

• Move decode_error.rs to its own crate
• Re-export solana_decode_error as decode_error in solana-program for backwards compatibility

[buffalojoec]

It appears to me that we can instead just eliminate this trait.

The decode_custom_error_to_enum is just indirection around FromPrimitive::from_u32, and it's only used in tests and impl PrintProgramError for ProgramError, which can just use FromPrimitive directly.

I also can't see where fn type_of() is used anymore. I can take the DecodeError impl out of some builtin program errors without issue, and I can change it within SPL programs and it doesn't affect anything as far as I can tell.

The direction would then be to use FromPrimitive::from_u32 directly within impl PrintProgramError for ProgramError and then deprecate the trait. What do you think?

[kevinheavey]

@buffalojoec makes sense, though CI fails when I do that because it requires a change to spl-token too:

error[E0276]: impl has stricter requirements than trait
   --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/spl-token-6.0.0/src/error.rs:100:15
    |
100 |             + DecodeError<E>
    |               ^^^^^^^^^^^^^^ impl has extra requirement `E: DecodeError<E>`

The PR to deprecate DecodeError is here #2046

[buffalojoec]

@buffalojoec makes sense, though CI fails when I do that because it requires a change to spl-token too:

error[E0276]: impl has stricter requirements than trait
   --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/spl-token-6.0.0/src/error.rs:100:15
    |
100 |             + DecodeError<E>
    |               ^^^^^^^^^^^^^^ impl has extra requirement `E: DecodeError<E>`

The PR to deprecate DecodeError is here #2046

Yeah that's expected. I left a comment over on that PR about taking a little slower deprecation approach. We can maybe leave this one open for a bit in case we decide it's better to go with the extracted crate.

[kevinheavey]

If we leave the DecodeError implementations in then we should still move it to a new crate imo, otherwise we can't do any more SDK splitting for a year or however long it is until the 3.0 release