space[i].enabled and space[i].unique must be boolean

[Kostja Osipov]

you can't use true/false for

space[0].enabled = 1
space[0].index[0].unique = 1

if you do, tarantool won't start.
This is inconsistent with the rest of boolean options.

Secondly, you can't set boolean options to 0/1. A boolean option should accept true/false, 0/1 and yes/no (this was implemented in confetti, but apparently doesn't always work).

[Aleksey Demakov (ademakov)]

The bug exposes a peculiar oddity wrt required boolean params in the current version of confetti. Namely there are two design choices in confetti that together render required boolean params unusable. That is

1. The parameter value in the template config is used both to infer the parameter type and to specify its default value.
2. There are currently no means to tell if the parameter was not set at all or it was set to the same value as the default. Hence for required parameters the validation phase raises the "Option XXX is not set (or has a default value)" error when the parameter is equal to its own default value.

The idiomatic use is that the default value for a required parameter is chosen to be beyond the domain of valid values for this parameter. For instance, NULL for string parameters, -1 for natural numbers, etc.

However boolean parameters have only two possible values. Therefore using one of them for a required parameter in the template config just forbids it in the real config.

Semantically, the problem is that the notion of default value does not apply to required parameters. If a parameter is required then it means exactly that it is not allowed to have a default for it. It must be explicitly initialized.

In order to resolve this problem there is a choice between two strategies:

1. Extend the confetti template grammar to allow specification of parameter types without specifying the default values. An easy way to do this is to add special values that bear only type information and no concrete data. For example, NaN for a number and Unknown for a boolean value. However extending the grammar introduces a set of new problems. Like should we allow such values only for required parameters or for all. Should we somehow extend the confetti API to handle such values, etc.

2. Change confetti internals so that it ignores the actual value of required parameters interpreting it not as the default value but as a 'sample' value. This way we don't need to change the external confetti interface (neither grammar nor API).

I believe the second choice is better. I implemented it only for boolean parameters for now. It could be expanded to other parameter types should the need arise.

[Kostja Osipov (kostja)]

Tarantool changes are OK, requested test coverage. OK to push with tests.

[Aleksey Demakov (ademakov)]

fixed in fix-bools branch