Trying to get away with returning a single code and parameter-list that
was supposed to represent both human-readable and machine-readable data
was a mistake.
This patch converts it to use DataMessageValue, which represents the two
separately and also provides guidance for supplying translations of all
the error codes.
This also eliminates the "describeSettings()" method that was trying to
serve multiple use cases (in terms of the Action API, action=paraminfo
and action=help). It's replaced by two methods that each serve one of
the use cases. Also some of the functionality was moved out of the
TypeDef base class into ParamValidator, to better match where the
constants themselves live.
Also I wound up creating a NumericDef base class so FloatDef can share
the same range-checking logic that IntegerDef has. I probably should
have done that as a separate patch, but untangling it now would be too
much work.
Bug: T235801
Change-Id: Iea6d4a1d05bb4b92d60415b0f03ff9d3dc99a80b
Parameter validation is based on parameter definitions like those in the
Action API, using the new ParamValidator library. Handlers should use
the provided Handler methods to access parameters rather than fetching
them directly from the RequestInterface.
Body validation allows the handler to have the (non-form-data) body of a
request parsed and validated. The only validator included in this patch
ignores the body entirely; future patches may implement validation for
JSON bodies based on JSON schemas, or the like.
Bug: T223239
Change-Id: I3c37ea2b432840514b6bff90007c8403989225d5
