rpc: fix invalid parameter error codes for {sign,verify}message RPCs

[theStack]

RPCs that accept address parameters usually return the intended error code RPC_INVALID_ADDRESS_OR_KEY (-5) if a passed address is invalid. The two exceptions to the rule are signmessage and verifymessage, which return RPC_TYPE_ERROR (-3) in this case instead. Oddly enough verifymessage returns RPC_INVALID_ADDRESS_OR_KEY when the signature was malformed, where RPC_TYPE_ERROR would be more approriate.

This PR fixes these inaccuracies and as well adds tests to rpc_signmessage.py that check the parameter validity and error codes for the related RPCs signmessagewithprivkey, signmessage and verifymessage.

master branch:

$ ./bitcoin-cli signmessage invalid_addr message
error code: -3
error message:
Invalid address
$ ./bitcoin-cli verifymessage invalid_addr dummy_sig message
error code: -3
error message:
Invalid address
$ ./bitcoin-cli verifymessage 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX invalid_sig message
error code: -5
error message:
Malformed base64 encoding

PR branch:

$ ./bitcoin-cli signmessage invalid_addr message
error code: -5
error message:
Invalid address
$ ./bitcoin-cli verifymessage invalid_addr dummy_sig message
error code: -5
error message:
Invalid address
$ ./bitcoin-cli verifymessage 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX invalid_sig message
error code: -3
error message:
Malformed base64 encoding

[maflcko]

Do we have guidelines on what error code to use?

[theStack]

Do we have guidelines on what error code to use?

Not that I know of, I was just orienting myself on what most other RPCs receiving address parameters use as error codes (see e.g.

git grep "RPC_.*Invalid address"

). Even without guideline I'd assume it's common practice to choose the most specific error code, and only use the more more generic one (like RPC_TYPE_ERROR) if none of the specific ones match.

[laanwj]

I think it's good to be consistent here, whether there are guidelines or not. To return the same return values for the same kind of errors over different RPC calls.

I do agree this change needs a release notes mention. Some people depend on specific return values, see e.g. talaia-labs/python-teos#37 (which is not relevant to this specific RPCs).

[theStack]

Added a relase note commit and rebased on master.

[DrahtBot]

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

Conflicts

No conflicts as of last run.

[luke-jr]

utACK

[meshcollider]

utACK a5cfb40

[laanwj]

Code review ACK a5cfb40