Description
We have a number of locations in code (fewer than I expected, but still) that interpret boolean(-ish) strings from settings.
Some spots handle (case-insensitively) all of "true", "on", "yes, "1" vs. "false", "off", "no", "0" values, others expect just one of those.
This PR is about consolidating the code to one method that can be easily used with old and new settings (e.g. in #2807 discussion), including those where some other non-boolean values are also anticipated, e.g. return -1 for non-boolean (so it can be parsed further or considered non-false/non-true by situation), 0 for false, 1 for true.
It would also simplify configuration for people, so they would not have to keep consulting the man pages where a 0/1 is needed, and where a yes/no, etc.
NOTE: The C++ code already handles that generically, so I suspect nutconf might in fact emit configurations that could be unreadable to those lines in our daemons that expect only a certain value, e.g. "1" while a "true" is in their config and ignored. Never checked for that practically though.
Maybe we would also need to extend augeas definitions for fields that anticipated one specific pattern (e.g. 0/1) to be more omnivorous.
See also #31 about common boolean type definition.