rpc: Assert that RPCArg names are equal to CRPCCommand ones (misc)

[maflcko]

This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:

Motivation

RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the CRPCCommands and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.

Changes

The changes here add an assert in the CRPCCommand constructor that the RPCArg names are identical to the ones in the CRPCCommand.

Future work

Here or follow up, makes sense to also assert type of returned UniValue?

Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:

• Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
• Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
• Auto-formatting and sanity checking the RPCExamples with RPCMan
• Checking passed-in json in self-check. Removing redundant checks
• Checking returned json against documentation to avoid regressions or false documentation
• Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static

Bugs found

• The assert identified issue rpc: Fix named arguments in documentation #18607
• The changes itself fixed bug wallet: Make RPC help compile-time static #19250

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• rpc: Add getindexinfo RPC #19550 (rpc: Add getindexinfo RPC by fjahr)
• rpc: fix/add missing RPCExamples for "Util" RPCs #18448 (rpc: fix/add missing RPCExamples for "Util" RPCs by theStack)
• Log RPC parameters (arguments) if -debug=rpcparams #16365 (Log RPC parameters (arguments) if -debug=rpcparams by LarryRuane)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[theStack]

Concept ACK. As far as I see, this mainly uses the new CRPCCommand constructor that was introduced in an earlier PR. Will review the main commit more in detail.

[maflcko]

Thanks, fixed leftover

[theStack]

ACK fa77de2
For a small code readability nit, I think it makes sense to re-indent after all RPC modules have been updated to use the new RPCHelpMan. The first few ctor arguments to RPCHelpMan seem to be over-indented, while the function body seems under-indented, which looks quite odd. Would personally prefer it like this:

static RPCHelpMan somecoolrpcmethod()
{
    return RPCHelpMan{"name",
        "\ndescription\n",
        {
            ...
        },
        RPCResult{
            ...
        },
        RPCExamples{
            ...
        },
        [&](const RPCHelpMan& self, const JSONRPCRequest& request) -> UniValue
        {
            ...
        },
    };
}

[laanwj]

I don't think multiplexing an argument on string/number type is generally a good idea. Because it's harder to use from some (statically typed) languages, and even from bitcoin-cli I think.. But for a test call ti's fine so no problem here specifically, but it's not something to encourage.

[laanwj]

Code review ACK fa77de2

[ryanofsky]

Code review ACK fa77de2. Pretty straightfoward changes

[fjahr]

tested ACK fa77de2

Reviewed code, used the new style from fa77de2 in #19550 and tested the change in echo.