Rudder

We need to check what we want to do with that, because that PR undo what was done in https://issues.rudder.io/issues/22357.

The problems are:
- if there is less custom-roles after a user update (for ex through user-managmeent plugin), then they must be discarded
- we need to correctly have plugin-provided custom-roles registered and kept on reload

But we must even tacke a bigger problem: what we do with plugin-provided authorizations for base role that "should" get them, like user and read_only regarding for ex system_update:read.

Option are:
- extends them with plugin provided permissions,
- force user to specify new permission, perhaps aggregated in new custom-role, and use these role in place of the rudder base ones
- perhaps have a different role for the expandable one and the non expandable one ?

The last option is complicated and we're not sure of the provided value, the second one is cumbersome and not what is expected, and the first seems to be what people expect, what we used to do in rudder, and it doesn't forbid anything: someone is still able to define a strict custom role from the exact list of permission he wants to give.

So we need to rethink that PR, and likely implement #1 in place of what was done here.