Ability to have multiple values for a Parameter in a Specification

[britram]

It would be useful to be able to say something like the following:

{ "specification": "measure",
  "parameters": { "source.ip4": [ "10.1.2.3", "10.4.5.6", "10.7.8.9" ] } }

We can't do this right now, since a parameter can only contain a single value.

It would seem useful to be able to flag a parameter as "promotable", or to have a new section for parameters capable of taking a list of values, which would be taken as a union set, and promoted to result columns in the result.

This requires some design work.

[britram]

"Multiple value parameters" should be (like capability parameter constraints) classified into three types:

1. sets of values (i.e., a list)
2. explicit ranges of values (do we actually need these?)
3. implicit ranges of values (in this case, nets with masks).

Semantics are also necessary for multiple value parameters in specifications:

• one: choose exactly one of the items in the list.
• all: choose all of the items in the list; in essence, this causes the multiplication of the specification by each of the values of the parameter.
• any: choose some of the items in the list, using a method specified by the receiver/component. Actually, I'm not sure this is useful; maybe we just need "one" and "all".

"Multiple value parameters" are like parameters (in that they are constrained in capabilities and specified by the client in specifications) and also like result columns (in that their values are also specified per row in results). This suggests one of the two following patterns:

1. MV parameters are potentially "marked" in capabilities, "marked" in specifications (by having lists instead of single values), and "promoted" to columns in results (i.e., they appear as result columns, not as parameters). It's not clear how to make sure that schemas match up across the capability-specification-result field, not clear what happens if a single value is given for a multivalue, and not clear if any parameter is promotable simply by giving it as a list.
2. MV parameters appear in their own section (multiparameters:?) and create new sections (multiparametervalues:) in results. This minimizes surprise, I think, but I can't come up with a good name for these, and adds yet another two sections to the Statement.

It's pretty clear that this facility brings with it a new mPlane protocol version.

[britram]

The requirement for this has been obviated by the creation of opaque multivalue parameters in a private registry for now.

[britram]

@dianajoumblatt There's an sdk-multival branch that has extremely experimental support for this now. A parameter is declared to be a multivalued parameter by placing its constraint in brackets. So, a single IP address would be (in JSON):

{"parameters": {"destination.ip4": "*"} }

while a multivalue parameter would ne:

{"parameters": {"destination.ip4": "[*]"} }

Constraint checking is implemented and passes tests. There is no API for this right now, a service can simply add_parameter, get_parameter_value, and set_parameter_value and get arrays of things as opposed to things. There's no support for this in the generic clients, and handling (1) lists of things and (2) how to report results in a semantically meaningful way is application-specific. Still need to write tests for this and add any missing code, will do after merging the test branch back to SDK.

[britram]

@gubser make some fixes to this, but there are still representation things to do in a non-hacky way.