Dune cache: add enabled-except-user-rules setting

[nojb]

This PR follows #10710.

It removes the recently introduced DUNE_CACHE_RULES (and associated config and command-line switch) and instead adds a new setting for DUNE_CACHE: exclude-user-rules (exact name can be tweaked). In this way, existing values of DUNE_CACHE keep their existing semantics so that no changes are needed from users who already set this variable (or the associated config setting). The documentation is adjusted accordingly.

[snowleopard]

This seems like a much better approach to me, thanks!

I'm only unsure about the new setting name: I think I'd prefer enabled-except-user-rules to align better with the two other settings.

[nojb]

I think I'd prefer enabled-except-user-rules to align better with the two other settings.

Indeed! Will adapt.

[nojb]

I think I'd prefer enabled-except-user-rules to align better with the two other settings.

Indeed! Will adapt.

This is now done: 7490811

[ElectreAAS]

This is almost exactly what I was cooking up on my side, except yours is cleaner, and you got a PR running faster than me ;)

Thanks a lot!

[ejgallego]

Great, thanks a lot @nojb !

The current name looks good to me, I wonder tho if the more relevant terminology here is safe/unsafe vs user/non_user in the medium term.

Indeed, "unsafe rules" are a bad user experience in many cases, and the notion of "sandbox" is something that seems users need to know. So in the future, we could imagine a more granular setup where rules are classified not according to their provenance, but according to "purity" or "safety".

[nojb]

I wonder tho if the more relevant terminology here

I hear you, but I though that "safe"/"unsafe" was going to be less clear to the average user than the more explicit enabled-except-user-rules. Also, for backwards-compatibility we will have to maintain the option introduced here with the same semantics in the future, even if we do something more sophisticated like classifying rules according to safe/unsafe; so we would not change the meaning of the option introduced here, but rather add a new setting enabled-except-unsafe-rules with different semantics. And lastly, since the new setting introduced here is the default, I don't think many people are going to set this explicitly in their environment, and so even if we wanted to change its meaning in the future, doing so won't be an costly operation, in terms of backwards-compatibility.