Allow marking a thread as blocking via a predicate

[minwoox]

Motivation

Our test suite uses an embedded Vert.x server:
https://github.com/fabric8io/kubernetes-client/blob/main/junit/mockwebserver/src/main/java/io/fabric8/mockwebserver/MockWebServer.java#L83

Vert.x utilizes FastThreadLocalThread for its blocking worker threads:

• https://github.com/eclipse-vertx/vert.x/blob/a4eaffdd9ead88d17a51d40480f9032dfe02e962/vertx-core/src/main/java/io/vertx/core/impl/VertxImpl.java#L201
• https://github.com/eclipse-vertx/vert.x/blob/a4eaffdd9ead88d17a51d40480f9032dfe02e962/vertx-core/src/main/java/io/vertx/core/impl/VertxThread.java#L23

However, Netty's BlockHoundIntegration classifies FastThreadLocalThread as non-blocking by default:
https://github.com/netty/netty/blob/4.2/common/src/main/java/io/netty/util/internal/Hidden.java#L189

This results in Vert.x’s blocking threads being incorrectly treated as non-blocking by BlockHound. Currently:

• There's no way to exclude or override the classification made by a third-party integration.
• While we can add custom non-blocking thread predicates, we cannot force-mark specific threads as blocking.

Suggestion

Introduce a method like BlockHound.Builder.blockingThreadPredicate(...) to allow users to explicitly mark certain threads as blocking, even if third-party integrations consider them non-blocking.

[violetagg]

@minwoox May be you can think about how to make use of this Netty feature?
netty/netty#12959

[minwoox]

Hi, @violetagg! Thanks for the feedback.
Yes, I've actually sent a PR to use the feature:
eclipse-vertx/vert.x#5637

I thought it might be necessary in some cases where you can't override the behavior enforced by a third party.
But it seems we don't need it now. Let me close this issue—thanks again!