Rudder

The first step in the parent ticket is to weave into rudder new CoreNodeFactRepository a notion of permission to see a node.
That notion will deal witht the domain design of "tenants" and needs 3 things:

- in the node, it needs a "tenant" materialization. For design model, we will name it SecurityTag which will hold a list of tenants (and perhaps later on other RBAC aspects for nodes, like fine-grained perms). This is internal and can be draft level, it won't be exposed directly, even with API.
- in user authorization, it needs a "tenant" materialization. This will be a new tenants attribute for users (a list of accessible tenants)
- in rudder code, a way to easily weave from interface point between modules who is asking for nodes, so that rudder can filter out them. This is a notion of QueryContext, which reflect ChangeContext for change.

That ticket will bring these changes but only so that we are able to test a full feedback loop from user definition (from the XML file, because we want to expose UX here) to node filtering in the UI (only node/node details pages, it's enought to see if the design fly). And it's OK is we have to set node's security tag by hand/ldap browser (not expose to users).