Allow registering a custom `Predicate` for determining non-blocking threads

[trustin]

Related issue: #3833 Motivation:

It is currently not possible to create a non-blocking threads without implementing the reactor.core.scheduler.NonBlocking interface. Some third-party libraries and frameworks don't directly depend on reactor-core, yet they want to mark the threads they manage as non-blocking.

Modifications:

• Added a new method Schedulers.registerNonBlockingThreadPredicate() so that a user can register their own Predicate that determines whether a given thread is non-blocking or not
  • Also added Schedulers.resetNonBlockingThreadPredicate() so that a user can reset the registrations.
• Fixed an incorrectly implemented test that doesn't really test anything:
  • SchedulersTest.isInNonBlockingThreadTrue()

Result:

• A user can now mark their own Thread classes as non-blocking without depending on reactor-core or implementing the NonBlocking marker interface.

[pivotal-cla]

@trustin Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@trustin Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@trustin Thank you for signing the Contributor License Agreement!

[chemicL]

Just noticed the branch is targeting main. As this is an additive change, I think we could ship this in 3.6.9. Or are you ok to delay this until 3.7.0? Adding functionality in patch brings a bit of an effort to the usages where the actual runtime library might have the API or might not so you need a way to check if you can register the Predicate.

[trustin]

That's a good idea, @chemicL. Let me send another PR that targets 3.6 soon. :bow:

[trustin]

@chemicL, I sent a new pull request for 3.6: #3854

[chemicL]

Thanks, closing this one then.