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]

If we misspell the extension name we can now produce a wrongly singed extrinsic

This takes an arbitrary string, maybe we can easily compare against metadata.extrinsic().transaction_extensions_to_use_for_encoding()?

[DenzelPenzel]

Good catch – a typo silently dropped the extension. DefaultTransactionExtensions::new now validates each custom name against metadata.extrinsic().transaction_extensions_to_use_for_encoding() and errors with "Custom transaction extension '{name}' is not present in the runtime metadata" if it is absent. Covered by custom_extension_absent_from_metadata_is_rejected

[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]

Do we plan to extend this? Maybe its easier to colapse and use directly Value?

[DenzelPenzel]

No plans to extend it, collapsed to Value directly, so the maps are now BTreeMap<String, Value> / Vec<(String, Value)>.

[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.