Draft: Bug in Variable handling

[adriaan42]

While working on #758, I noticed a bug in the way variables are handled:

Currently, there is one global Variables object, as member of the global Application. When loading profiles, variables are added to it, but never removed. So when switching profiles, there are still variables present from the previous profile.

To demonstrate, use the debug print from the first commit of this PR, with two profiles:

• Profile variable1:

  [variables]
  foo=42

• Profile variable2:

  [variables]
  bar=23

Then use tuned-adm profile to switch between them, and note how the debug output will contain not only variables of the current, but also of the previously loaded profile:

[... started with profile variable1 active ...]
2025-03-10 08:58:57,683 INFO     tuned.profiles.loader: loading profile: variable1
2025-03-10 08:58:57,688 DEBUG    tuned.daemon.daemon: BUG: variables=dict_keys(['(?<!\\\\)\\${foo}'])
2025-03-10 08:58:57,688 INFO     tuned.daemon.daemon: starting tuning
[... tuned-adm profile variable2 ...]
2025-03-10 08:59:21,570 INFO     tuned.profiles.loader: loading profile: variable2
2025-03-10 08:59:21,571 DEBUG    tuned.daemon.daemon: BUG: variables=dict_keys(['(?<!\\\\)\\${foo}', '(?<!\\\\)\\${bar}'])
2025-03-10 08:59:21,571 INFO     tuned.daemon.daemon: starting tuning

My proposal is to have the Variables object owned by the Profile. It is created by the profile loader, so that more complex load scenarios (multiple profiles, potentially with includes) still only use one Variables object.

An alternative would be to simply clear variables when loading a new profile, but that would break my #758, where (when restoring a snapshot) a second profile is loaded, which can fail, and therefore does not work well with Variables as global state.