feat: support custom transaction extension values

[DenzelPenzel]

Summary

Allow callers to provide metadata-aware values for custom transaction extensions without implementing a new Config:

let params = PolkadotExtrinsicParamsBuilder::new()
    .custom_extension("RestrictOrigins", true)
    .build();

The value is encoded against the extension type from runtime metadata. This fixes signing on chains such as Paseo Asset Hub, where RestrictOrigins contains a bare bool.

Fixes #2265.

Implementation

• Preserve known default extension behavior and parameter access.
• Encode custom values using runtime metadata.
• Reject duplicate names, overrides of known extensions, and non-empty implicit data.
• Restore the output buffer on encoding errors.

Breaking changes

DefaultTransactionExtensions<T> and its Params type changed from public tuple aliases to structs with private fields, so that custom extension values can be carried alongside the known ones. The tuples live on under new names: KnownDefaultTransactionExtensions<T> and KnownDefaultExtrinsicParams<T>.

Code which configures transactions via the builder and passes the params through opaquely is source-compatible and produces byte-identical transactions. Code which relied on the tuple shape of the params migrates as follows:

Before	After
constructing the params tuple manually	DefaultExtrinsicParams::from_known(tuple)
mutating an element, e.g. params.5 = ...	params.known_mut().5 = ...
reading an element, e.g. &params.7	&params.known().7

Given the above, this should land in 0.51 rather than a 0.50.x patch.

Notes

• The V5 extension-version selection part of the issue is deliberately out of scope here; it is tracked in Always use transaction extensions version 0 when working with v4 transactions, and find latest match when using v5 #1998.
• Custom authorization extensions and custom extensions with non-empty implicit data are not supported; the latter returns a clear error naming the extension.
• Includes a drive-by cargo fmt fix for two test asserts that landed unformatted on master.

[lexnv]

nit: This forwards only to known entries, so chain specific exntesions return false here? Would be worth having a subxt issue about this one to tackle later

[DenzelPenzel]

Filed #2276 for this, and left a comment on is_authorization_extension pointing at it.

Worth noting it is not purely cosmetic: in V5 the signer payload excludes the last authorization extension and everything before it, so a chain declaring its own authorization extension and supplying it via custom_extension would sign over bytes the runtime excludes. Latent for now since VerifyMultiSignature is the only authorization extension Subxt knows about.

[lexnv]

The shape looks good, just some tiny bits and pieces!

We could probably add some more V5 tests (ie around authorization_extension_check_is_forwarded and is_authorization_extension and probably some tests with a custom extension positioned before and after VerifyMultiSignature)

[DenzelPenzel]

Added the V5 coverage you asked for. Since polkadot_metadata_small.scale only declares v4 and has no VerifyMultiSignature, there is a new v5_encoding_info() helper laying out [CheckWeight, VerifyMultiSignature, WeightReclaim] – a custom extension either side of the authorization extension:

• v5_payload_excludes_custom_extension_before_authorization_extension – flipping CheckWeight leaves the signer payload hash unchanged, since it precedes VerifyMultiSignature.
• v5_payload_includes_custom_extension_after_authorization_extension – flipping WeightReclaim does change it, since it follows.
• v5_general_extrinsic_includes_custom_extensions_either_side_of_authorization – the extrinsic itself carries every extension value regardless of position, unlike the payload.
• authorization_extension_check_is_forwarded also now asserts false for a known non-authorization extension (CheckNonce) and for a name not held at all.

The is_authorization_extension gap for chain-specific extensions is tracked in #2276.

[TarikGul]

Left a few comments inline.

[lexnv]

Nice job here @DenzelPenzel! Feel free to merge after addressing Tarik's comments and the tiny ones from my side 🙏

[TarikGul]

🚀 Thank you