Fix PluginBuildPluginTests on mac

[alpar-t]

We skip the thread leak check because it seems Gradle is leaking them
and there's nothing we can do.

Closes #47417.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Build)

[rjernst]

What changed in gradle? This seems to have come about not from an upgrade of gradle, but from changes in our build. I'm concerned relaxing this check is only opening the door for us doing something silly in our build. Applying a plugin should not be spinning off threads?

[alpar-t]

@rjernst we didn't have a Test like this before, it's a newly added one , so we just saw this now. It's very hard to track this down, since the build plugin does a bunch of things. Perhaps we can get back to this once we manage to chop it up a bit ? I understand and share your concern, but since we don't start threads as part of the build at all, and this only happens on mac I'm fairly sure this is a Gradle issues and one that will take a lot of time to chase down that could be put to better use right now

[rjernst]

With @mark-vieira I tracked this down to GlobalBuildInfoPlugin, which uses project.exec on macos. It appears gradle is using some kind of pooled executor, which keeps threads around for future exec calls.

Instead of masking all threads, can we use a threadfilter? I think this should apply in the base gradle test case as it could happen with any projectbuilder, we just haven't hit it yet because nothing was applying GlobalBuildInfoPlugin in code.

I think the filter would look something like this:

On GradleUnitTestCase

@ThreadLeakFilters(defaultFilters = true, filters = {
    GradleExecThreadsFilter.class
})

And a new class:

public class GradleExecThreadsFilter implements ThreadFilter {
    @Override
    public boolean reject(Thread t) {
        return t.getName().startsWith("Exec process");
    }
}

[rjernst]

I opened #47713 with my above suggestion (it passes for me locally).