bip138: clarify key selection and apply exclusions across expressions #2300

This PR clarifies which keys can decrypt a BIP138 backup.

It expands the existing exclusion rule to consider all descriptors and key expressions in the backup. This makes encryption safer, but does not impact decryption, so it's not a breaking change.

Four middle commits:

• generalize key-selection test vectors: rename keys_types.json to recipient_keys.json and support lists of descriptors and expected keys, preserving the nine existing cases.
• clarify MuSig participant eligibility: add two vectors, clarify that the participant xpubs should be used, not the aggregate key
• collect and deduplicate recipient keys across the backup: deduplicate across all descriptor / policy sets.
• exclude roots exposed by another expression: three test vectors: bare/derived reuse, an opposite-parity literal, and a MuSig participant exposed in a script leaf.

The first commit introduces a changelog. I'm reusing that commit across a few parallel pull requests.

The last commit updates the changelog; I'll update that depending on merge order.

cc @pythcoiner, see also #2298 and #2299

Seems reasonable, waiting for @pythcoiner to chime in.

@Sjors, about bip138: exclude roots exposed by another expression I'm wondering if we should not even be more strict: only use keys expressions that have at least a wildcard or a multipath

let's take the example of wsh(or_i(pk(X/0/*),pk(Y))), here Y has not link to X, but the key will end up on chain, so anyone that get the encrypted payload could easily bruteforce by trying all onchain keys?

@pythcoiner can you explain your example a bit more? IIUC Y is already excluded because it's a bare xpub or pubkey.

@Sjors my bad, you are right

ACK bf63b1d9

Thanks, @Sjors and @pythcoiner. I rebased the PR to fix the merge conflict on version and Changelog.