improvement(RPC): unified interface for legacy and current RPC interfaces

[onur-ozkan]

Allows using any (legacy or current) RPC methods without needing to include mmrpc in the RPC payloads. It has been annoying to constantly add and remove that field between different RPCs. With this PR, we can leave it to KDF and it will handle it automatically. Ideally, we should remove it entirely from the codebase but that would cause breaking change for downstreams.

[onur-ozkan]

This was testing unknown methods on the legacy dispatcher (not very useful to cover to be honest). The behavior for unknown RPCs in the legacy dispatcher has changed: if a method isn't found there, we now try to find it in the current dispatcher.

[smk762]

Please let me know how this would affect docs. A simple find/delete for the param is simple enough, and v2 methods tend to include a params object which the equivalent v1 method does not. In some cases tho, like get_enabled_coins which does not take any params, the v1 and v2 methods will be indistinguishable.

{
    "userpass": "{{userpass}}",
    "method": "get_enabled_coins"
}

{
    "userpass": "{{userpass}}",
    "mmrpc": "2.0",
    "method": "get_enabled_coins"   // "params": {},
    // "id": null // Accepted values: Integers
}

The response structure of these is also significantly different:

v1:

{
    "result": [
        {
            "ticker": "DOC",
            "address": "RUYJYSTuCKm9gouWzQN1LirHFEYThwzA2d"
        },
        {
            "ticker": "MARTY",
            "address": "RUYJYSTuCKm9gouWzQN1LirHFEYThwzA2d"
        }
    ]
}

v2:

{
    "mmrpc": "2.0",
    "result": {
        "coins": [
            {
                "ticker": "DOC"
            },
            {
                "ticker": "MARTY"
            }
        ]
    },
    "id": null
}

Will "mmrpc": "2.0" remain in the response?

This PR effectively removes any v1 method with a v2 version. Will there be a way to force v1 if needed for some reason?

[dimxy]

My note about this approach (I already asked this in the internal channel):
we have methods with identical names for legacy and v2 APIs, like "trade_preimage".
In such case this PR may fail on the legacy method instead of switching to the v2 method. That way, the user needs to know about that and use "mmrpc": "2.0" explicitly in this case (identical method names). Hm-m.

[onur-ozkan]

Covering both comments above:

If you are using mmrpc parameter, you won't notice any difference at all; everything still works as before. If it's not set and the requested RPC isn't found among the legacy RPCs, it will now also check mm2rpc 2.0 before returning "not found".

[borngraced]

non blockeers

[laruh]

Thanks, only one note

[laruh]

LGTM!

[dimxy]

Should we not first try rpc version 2 rather than legacy?
to make preference for v2, in case of identical rpc name for v2 and legacy

[onur-ozkan]

This approach will cause BC on identical RPC names as they don't set mmrpc field.