Rudder

In 2.10 and above, the calculus of compliance for a rule (or for a node) is done within the display code (RuleEditForm mainly).

That violates any best (or even good) practices I can think of, including:

- it mixes displaying and business logic, make change in one or the other both harder and more error prone than if the orthogonal subject where actually in different part of the code (try to drive an helicopter to understand that)
- the code is not reusable, so we can't build new services using the logic (API, component using it elsewhere...)
- it's not DRY, and so bugs are jumping from screen to screen
- we can't optimize the business logic performance
- and moreover, we can't make things impossible by construction, so we spend more time checking normally impossible to reach state
- we can't evolve the business logic (for example, #4750, knowing if a set of repaired report should be "repaired" or "error" (is pure business logic, not displaying)
- we can't build the UI from a stable datastructure / service layout

So we need to:

- specify what we NEED from a compliance point of view (by rule ? by node ? bulk ? only the last one ? etc)
- specify the datastructures in use now
- split anything dealing with displaying (human name, etc) from business logic (where we get data from ? When ? How do we transform them ? What are our contracts with the caller ? What are the datastructures ?)
- refactore RuleEditForm the use the new services