Rudder

Historicaly, we only split node configuration and corresponding compliance in two:
- the system (as in "Rudder itself") configuration/compliance, checking for the well being of the infrastructure (rudder agent configured, etc)
- the user configuration/compliance, ie all the technique/directive/rules configured by user on nodes.

The node configuration are in base for some time now, but the compliane result themselves are pure computation done from configuration and node "runs".

This is too limiting, because we want to be able to differentiate more than just between system/user compliance:
- for system, we have plugin-specific policies that are not really system, but clearly part of the underlying, not-user-exposed things - typicaly, policies for system update campaign. For now, they are marked "system", but that gives surprising effects
- for user compliance, in fact we want to be able to have several user compliance: typicaly, in the case of an hardening set of policies, it will be user-directed and configured, but we don't want it to be merged with main, basic user compliance.

This is also too limiting, because we want to be able to have different compliance validity for different aspect of compliance, and not rely on potentially very heavy computation each time we need them (or keep around extremely big datas to be able to redo the computation if we only have a cache).

So we would like to put these node-compliance-by-feature in base.

The main idea is simple:

- add a tag compliance:namespace on technique/directive/rules that is inherited by aggregation and allows to sort compliance reports,
- when computing compliance, save each shard in base for a node, so that a node has access to its base compliance, system compliance, campaign compliance, etc.

That feature will also use / integrate with the table added for Rudder score in Rudder 8.1.