Build: If integration testing is disabled we should probably assert that there are no integration tests

[nik9000]

@costin found some integration testing left laying around in a gradle project that has the integTest case task disabled. It'd be nice if we could automatically detect that sort of thing. We do some of that now with the naming conventions task, but I think maybe we should revisit that.

[elasticmachine]

Pinging @elastic/es-core-infra

[nik9000]

This is similar in spirit to #33524

[alpar-t]

We would need a way to fail the build if the flowing conditions are all met:

• integTest task is disabled (enabled = false)
• There are tests that match the integ test naming convention ( mostly end in IT )
• There is at least one test that does not have the @Awaitsfix annotation.

This last one is so we can still disable the task when all tests are muted.
On the other hand, while we are collecting information about muted tests, we could flip it and automatically disable if all the tests are muted so this would become lesser of an issue to begin with. If we do that, I don't think there's still a valid reason to disable the testing task, other than disabling the test task added by Gradle.

[alpar-t]

This is partially addressed in #36107.
Right now, any class that resembles a test (method names, annotations, etc) must be part of an enabled testing task. So if we disable a testing task this will no longer hold true and we will detect it, but this leaves us without a way to mute all tests for a task.
To solve this I will change randomized testing task not to fail on empty, and add a check to forbid testing task without classes.