Kanas/module invalidity

[Kanasjnr]

Description

This PR implements descriptive module invalidity support for transactions as proposed in #11337. It extends the InvalidTransaction enum with a new Module(ModuleError) variant, allowing pallets to return pallet-specific, descriptive error data during the transaction validation phase (e.g., in TransactionExtension).

Closes #11337

Integration

Downstream projects and UI tools (like subxt or polkadot-js) can now leverage descriptive invalidity reasons. When a transaction is rejected by the pool with a Module error, the RPC will return a formatted message including the pallet index and the error bytes.

Example RPC error output:
"Invalid Transaction: Module error: index: 5, error: [1, 0, 0, 0]"

Client-side libraries can use this index and byte array to look up the specific error definition in the chain's current metadata, mirroring how DispatchError::Module is handled today.

Review Notes

The implementation follows the established pattern for descriptive errors in Substrate while ensuring 100% backward compatibility for the transaction pool and node-side logic.

Key Changes:

• sp-runtime: Appended Module(ModuleError) to the InvalidTransaction enum (index 13). This position ensures that existing SCALE-encoded variants remain unchanged.
• String Conversion: Updated the From<InvalidTransaction> for &'static str implementation to prioritize the descriptive message from ModuleError if present.
• RPC Layer: Enriched both the Author RPC (v1) and the Transaction RPC (v2) to explicitly handle the Module variant and return formatted debug information.
• Verification: Added a new unit test module_invalidity_should_encode_and_decode in sp-runtime to verify the encoding/decoding and string conversion paths.

Integration Diff:

 pub enum InvalidTransaction {
     ...
     UnknownOrigin,
+    /// An error in a module.
+    Module(ModuleError),
 }

[Kanasjnr]

/cmd label T1-FRAME T3-Client D2-substantial I5-enhancement

[Kanasjnr]

/cmd prdoc --audience node_dev runtime_dev --bump minor

[Kanasjnr]

@gui1117 ready for review

[gui1117]

Some comments, I don't know the best direction, I feel like reusing pallet errors is not so clean.

[gui1117]

Reusing the same kind of type as ModuleError is good. We want a small embedabble information. But maybe the name Error make it confusing with dispatch error. And reusing the same error type for module dispatch error and invalidity can be confusing in the future. Like using 'into' will no longer mean anything, it could convert to an invalidity or a dispatch error which has a very different consequence.

So maybe we want a new metadata information for module invalidities, etc...

It would be cleaner but it is also more work.

In the current shape it feels like pallet errors are now just a type for succint information.