Values that are documented as "nonnegative integer" in Pacemaker Explained are validated as positive integers in libcrmcommon; which one is correct depends on the option.
The "score" type isn't used consistently. For example, `stonith-max-attempts` is a score value but it must be positive; if it's less than 1, the default is used.
There are also some precision discrepancies: Pacemaker Explained documents integers and nonnegative integers as 32-bit with `INT_MAX` as the max value, but that's not always the case; sometimes we support 64-bit integers or 32-bit unsigned integers.
Having a percentage type feels like overkill and accepts some invalid values as long as the first characters are valid (we accept "80%asdf" for example). IMO a float type makes more sense (e.g., "0.8" instead of "80%"), but `load-threshold` was already documented in the metadata as a percentage type so we're stuck with it for a while.
---
A good approach might be to have a single integer type with allowed values specified somehow. This single integer type may or may not include "score", which is capped at both ends upon overflow.
We could do textual descriptions of allowed values, but I think for the sake of parsing, something like the following might be best.
* Add an allowed-values field to option tables in Pacemaker Explained. In code, reuse the existing `pcmk__option_t:values` field, which is currently used only for `select` types (equivalent to `enumeration` in Pacemaker Explained).
* For integer values, allow a range, as specified by the range value type documented in Pacemaker Explained.
* For enumeration values, allow a comma-separated list of values, similar to the current `pcmk__option_t:values` field for `select` types in code.
* We could also allow a comma-separated list of ranges for integers, if there's any need for that.
Pros:
* Fairly easy to parse both visually and by machine. A parser can interpret the allowed values either as integer ranges or as strings, depending on the value type.
* Reuses some existing structure.
Cons:
* It's painful to specify low and high values that are dependent on the underlying data type. This is especially true where the data type is machine-dependent. For example, suppose an option's value is stored in an `int` variable. An `int` must be at least 16 bits, but it could be (and usually is) 32 bits.
* Adding another column to the Pacemaker Explained tables could make them uncomfortably wide.
Ref
* https://github.com/ClusterLabs/pacemaker/pull/3297#issuecomment-1867185988
* https://github.com/ClusterLabs/pacemaker/pull/3399/files#r1552031807