Add `optional` key to config values as mutually-exclusive with `default`

It is sometimes handy to use the presence of a scalar to trigger some conditional behavior. For example: a radius, which when set will add the flag --radius to the algorithm's command-line invocation.

This conflicts with the manifest's need to provide firm assurances to the gear as to the structure of data it will be provided. For example: many languages cannot distinguish between a set, falsey / zero value, an unset value, or a null value. This ambiguity would make it difficult or impossible to correctly process a manifest.

So: let's make it opt-in. The optional key marks that a value may or may not be present at all in the config.json. This is mutually-exclusive with default, since it would be ambiguous to resolve the two.

Caveat: Depending the interface a consumer uses, an optional string value may not be very helpful. For example: in the web interface, empty strings should be sent if not filled out. @lmperry and I discussed this and it seems fair that since the algorithm opted into this, it's reasonable to have it deal with that.

This value is always provided, and defaults to zero:

"speed": {
    "type": "integer",
    "default": "0",
    "minimum": 0,
    "maximum": 3,
    "description": "How fast do you want the gear to run? Choose 0-3."
}

This value is only provided if set, including zero:

"speed": {
    "type": "integer",
    "optional": true,
    "minimum": 0,
    "maximum": 3,
    "description": "How fast do you want the gear to run? Choose 0-3."
}

This value is (probably) always provided by a web interface, and provided if set by a CLI interface:

"name": {
    "type": "string",
    "optional": true,
    "description": "What is your name?"
}

flywheel-io / gears

Add `optional` key to config values as mutually-exclusive with `default` #25