Don't update tracker js files while testing #17155

Description:

The CustomTrackerJS plugin is enabled by default and tries to update the tracker js files whenever certain events are triggered. Those events include the creation of a site and other events that are triggered a lot while testing.
This PR disables the event listening for that plugin while testing, and only enables it for those tests where it is actually needed.
This should speed up the tests as it also avoids a lot file operations.

Review

• [ ] Functional review done
• [ ] Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• [ ] Security review done see checklist
• [ ] Code review done
• [ ] Tests were added if useful/possible
• [ ] Reviewed for breaking changes
• [ ] Developer changelog updated if needed
• [ ] Documentation added if needed
• [ ] Existing documentation updated if needed

btw be good to check if this actually speeds up the tests a lot. If it's just a minute or less then it might not be worth it merging as we had issues with it in the past and it can be good to have the tests cover this logic. Eg when a plugin gets activated, and adds tracking code or does something else with tracking code, and then reads a DI config as part of this but because the plugin was earlier not loaded the DI config was not read then it fails. Generally we'd want to to run this code. Or if the file system is slow to write the changes then we could simply store it in memory or so instead of writing it to disk (but then we'd probably also need to read from memory and then things get complicated and might not be worth it).

This doesn't seem to have an effect for any test suite, except the first system test build:

4.x-dev:

this pr:

(I restarted the 4.x-dev build so it's repeatable.)

This suggests some or one of the core system tests needs this while it's ok to run in other tests. Maybe we can find where specifically it's causing a big problem? Assuming it's better to run as much code as possible during tests.

@diosmosis I'll simply close this one. Guess the long run time on 4.x-dev was randomly.
The reason for creating this PR was that while debugging some tests I saw that generating the javascript files is triggered very often when setting up a test fixture. That's caused by the events triggered while activating plugins and stuff like that.