Rudder

This is the remaining part of #6733, where we allow user to use node propertise in directives parameters. These node properties will be replaced by their value at generation time, so that they can be used (for example) as input for JS transformation.

The chosen format for ncf technique, as documented in http://www.rudder-project.org/doc-3.1/_using_properties.html, is the following:

${node.properties[datacenter]}

And you can descend into a json structure:

${node.properties[datacenter][europe][france]}

We must use the same in directive, at least for the data access.

Question: do we want to let the possiblity to have in a directive parameter

${node.properties[datacenter]}

to tell "I really want that to be changed at runtime, and not at generation time", and so for node properties that have to be change at generation time, use something like

${rudder.node.properties[datacenter]}

Open question 2: what to do if the key sequence does not exists ? (i.e, in the example, [datacenter] is not defined) ? The possible option are:

1/ fails the generation, "missing property blabla in nodes node1, node2, node3
2/ use a default value (empty string, the string "null", etc)
3/ actually returns ${node.properties[datacenter]

The sanest (less surprise, fails early) is clearly 1/, but it certainly can lead to unpleasant case where one node block the whole generation (until rudder is able to generate policies node by node).
2/ and 3/ are variation of the same poison, and WILL lead to unexpected behaviour and surprises (anybody looking for "rm -rf ${prop1}/{prop2}, where neither are defined and so replaced by "" ?). On the other hand, it is much less frustrating when you are in an urge to deploy something and rudder keeps telling that their is 200 nodes with incorrect properties. And for the ncf/technique part of the feature, it's the behaviour (3/ actually, I believe).