Related to zonemaster#1105.

A subtle bug could cause RPCAPI methods, whose parameters were validated
against JSON schemas generated with JSON::Validator::Joi, to skip
validation of parameters against that schema entirely.

The offending code took a $method_schema, which could either be a raw
Perl hash containing a JSON schema or an opaque object made with
JSON::Validator::Joi, and tried to check whether the schema specified
any keys as required. It did so by checking whether the 'required' key
exists in $method_schema.

This works fine if $method_schema is a Perl hash. But when it’s a
JSON::Validator::Joi object, we are touching an implementation detail of
that class, which could sooner or later break!

And indeed, it broke: between JSON::Validator version 5.02 and 5.03, an
implementation detail was changed, causing issue zonemaster#1105 on systems where
JSON::Validator version 5.03 or later is installed. The change seems to
have been introduced by commit 788fd42 [1] on JSON::Validator’s Github
repo [2].

[1]: jhthorsen/json-validator@788fd42
[2]: https://github.com/jhthorsen/json-validator

Calling the RPCAPI endpoint with a number or a string instead of null or
an object caused a “500 Internal Server Error” to be returned, instead
of a propre RPCAPI error. This was due to the offending code failing to
check whether we were passed a hashref before attempting to dereference
it and checking the existence of an “id” key in it.

According to the specification, IDs must be strings, numbers (although
numbers with fractional parts are discouraged) or null (also
discouraged, but permissible). We might as well enforce it.

There was another situation where JSON schema enforcement could be
skipped: when a method only has optional parameters and the “params” key
in the JSONRPC object was set to something, the value of that key was
not validated.

The offending code skipped validation altogether if none of the method’s
parameters is required. What was probably meant is that if none of the
method’s parameters are required, then the absence of a “params” key in
the JSONRPC object is acceptable. But a method requiring no parameters
doesn’t mean that it has no parameters at all (e.g. when a method has
default values for all its parameters), so validation should still be
done on a “params” key if it’s there.

The rewritten code implements a different, but more correct logic: if
the “params” key exists, validate its value and return an error if it
fails validation; if the “params” key does not exist and the method
requires at least one parameter, then return an error; else return
success.