ACK 31ffd77

ACK 31ffd7782bf241ca09c7e192769ae9506bd2352f

• Built branch locally and exercised various manual test using both versions of the RPC
• Verified that passed in arguments get accepted
• Throws error when passing in options argument + additional invalid arguments

Light code review ACK baf99a9c789779e89e7684a550e16cf1fb7ce862

Code review ACK 40143ba.

This is a pretty simple change to the RPC framework that should make it easy to add new options to RPCs like createwallet that currently accept too many positional parameters, without having to increase the number of positional parameters they already accept.

Without this PR, the only ways to add a new options to an RPC like createwallet without breaking backward compatibility are to add the option as a top-level parameter, where it can be specified as:

bitcoin-cli -named createwallet wallet_name option_name=option_value
bitcoin-cli createwallet wallet_name null null null null null null null option_value

or to add a new OBJ_NAMED_PARAMS parameter where it can be specified as:

bitcoin-cli -named createwallet wallet_name option_name=option_value
bitcoin-cli createwallet wallet_name null null null null null null null '{"option_name": "option_value"}'

The first approach is unsafe because it allows option_value to be specified by position instead of name in an error prone way when there are too many positions. The second approach is safe, but not very appealing because it still increases the number of positional arguments, and doesn't display the old and new arguments in the same way in the documentation, or allow them to be accessed in the same way in the RPC implementation.

By contrast, this PR allows completely modernizing RPCs that accept a lot of positional parameters while retaining backwards compatibility. E.g. it would allow a new createwallet option to be passed as:

bitcoin-cli -named createwallet wallet_name option_name=option_value
bitcoin-cli createwallet wallet_name '{"option_name": "option_value"}'

And it would show all options consistently in the documentation, and give callers ability to pass every option as a named parameter or as a field in an options object.

Notes on how this PR works:

• The first commit "RPC: Support specifying different types for param aliases" (04d7864) allows multiple types to be specified for parameters if the parameters have aliases, like: "options|sign", {RPCArg::Type::OBJ_NAMED_PARAMS, RPCArg::Type::BOOL}. It enforces that the number of types is the same as the number of aliases. Previously it was only possible to specify a single type for a parameter, even if it had multiple aliases. Additionally:
  • It updates the RPCArg::MatchesType() function used to validate incoming RPC requests to accept any of the types specified in the list, instead of just the first type. If named parameters were passed, this commit does not enforce that the specific type corresponding to the named alias was used, but the third commit fixes this.
  • It fixes RPCHelpMan::GetArgMap(), which is used to generate bitcoin-cli -regtest help dump_all_command_conversions output, to output the correct type for each alias, instead just outputting the first type.
• The second commit updates walletprocesspsbt to take advantage of the support for alias types added in the first commit. Specifically:
  • It changes the second parameter from "sign" accepting a bool to "options|sign" accepting an options object or a bool.
  • It copies former definitions of the parameters 2-5 ("sign", "sighashtype", "bip32derivs", "finalize") into the options definition so they can be passed as options or named parameters by RPC clients.
  • It keeps parameters 3-5 intact but marks them as hidden. Keeping these parameters allows clients to continue to pass them as positional parameters instead of as named parameters or options fields.
  • It marks all the options {.also_positional = true} to avoid errors from the RPC framework about options and parameters having duplicate names.
  • It updates the implementation of walletprocesspsbt to read options and named arguments out of the options object, but keeps code for reading positional arguments out of the params object if no options object is present.
• The third commit adds stricter type checking to ensure that if a parameter has multiple aliases and each alias has an assigned type, and the parameter is passed by name instead of position, the parameter must have the expected type for that name. This prevents a bug described #24963 (comment), and the fourth commit just adds a test for this bug.