Fix the TunableGroups.is_updated() logic

[motus]

Summary of changes:

• Set the CovariantTunableGroup._is_updated flag only when assigning its tunables the data that is different from the tunables' current values.
• Add unit tests to verify the new behavior of the TunableGroups.
• In the Environment.setup() method, write to the log if the environment has to be reset due to the update to its tunables.

We will update the logic of the derived Environment classes in the subsequent PRs.

[bpkroth]

Summary of changes:

• Set the CovariantTunableGroup._is_updated flag only when assigning its tunables the data that is different from the tunables' current values.
• Add unit tests to verify the new behavior of the TunableGroups.
• In the Environment.setup() method, write to the log if the environment has to be reset due to the update to its tunables.

We will update the logic of the derived Environment classes in the subsequent PRs.

Awesome! I was encountering some of this recently as well. I think we can really improve the speed of trial repeats if we're only changing certain variables so we don't need to go through the full setup/teardown of the different environment levels.

It's going to get complicated when we start considering client/server split trees though, and we may need to implement some sort of "depends on" waiting feature at some point too, especially for parallel runs, but again - future work :)

[motus]

Yes, changing the tunables in one environment can affect other environments up the stack, and we have to handle that correctly. rn I am debugging exactly that for our Redis setup

[bpkroth]

LGTM