Fixes #23856: Impact of RBAC node filtering on compliance

[fanf]

https://issues.rudder.io/issues/23856

So this PR brings several things:

• (a port of Fixes #23920: Lift Async system is not able to find spring SecurityContextHolder #5267)
• make compliance computation aware of QueryContext
• the last one is a technical change so that QueryContext are provided in API authzToken parameter, and so we are really able to start porting APIs.

Where is the compliance computation update to handle node tenants?

Well, there is none, because we did the things correctly: compliance computation takes a list of nodes and everything is node-centric. So we are just passing the correct list based on the user tenant, and most of the changes are just about "correctly weaving from web context to compliance computation the QueryContext to be able to have the list of node based on tenants".

The main change is in RuleApplicationStatusService.isApplied and RuleValService.buildRuleVal and in ComplianceAPIService (reportingService.findDirectiveNodeStatusReports) that now uses the restricted list of nodes.

Evolving user authz availability in requests

That PR (finally) allows to have the user node permissions correctly threaded in all request contexts, be them in UI or in API.
It needed mainly two things:

• (yet another) change in CurrentUser so that we correctly set its value from spring security result in all context (normal session UI, comet/async case, stateless API requests)
• a change in what is the standard authzToken in API: in place of just getting the actor, it now holds a full QueryContext with also NodeSecurityContext. The actual change is trivial and happens in webapp/sources/rudder/rudder-rest/src/main/scala/com/normation/rudder/rest/ApiAuthorization.scala: we already had the user at end with correct info, so just use them.

Most of the remaining changes are boring declaration of implicit val qc: QueryContext = authzToken.qc in all API that needs them.

Using MapView in more places

Our CoreNodeFactRepository#getAll was changed to use MapView in place of a new Map or something else in a previous commit to avoid a too big refactoring and help with performance.

In that PR, we see that is seems to work very well: we have a lot of cases where we were filtering on nodeInfoService.getAll result to just map values to know the node's isPolicyServer or policyMode.
By having the MapView, we avoid a lot of intermediary copies (which were not really needed).
There was also a lot of places where MapView was used so we are just removing more collection creation.

This is a rather impacting change, it touches a lot of place, but it is rather trivial : now that Scala clearly differentiate between Map and MapView, the compiler tells us where we need to concretize the view.

Switching from NodeInfoService to CoreNodeFact

This is rather easy a normalized. CoreNodeFact is a super-set of NodeInfo, so we don't miss any data.
At several places, I was able to reduce the refactoring need by relaxing the parameter: we were asking for Map[NodeId, NodeInfo] but really using only nodeInfo.isPolicyServer for example. I think it used to be done like that to avoid more collection duplication/transformation.
With the previous change about MapView, I was able to pass MapView[NodeId, Boolean] without new collection copy, and without the need to switch from NodeInfo to CoreNodeFact (but yes, I had to switch from NodeInfo to Boolean ;) )

[fanf]

PR updated with a new commit

[VinceMacBuche]

There is a conflict on currentUser (i guess PR with spring/lift)

[Normation-Quality-Assistant]

OK, merging this PR