Add beginDispatch/endDispatch to VertxContext

[gastaldi]

Summary

• Add VertxContext.beginDispatch(Context) and VertxContext.endDispatch(Context, Context) static methods to both vertx4-context and vertx5-context modules
• These methods wrap ContextInternal.beginDispatch() / endDispatch() so that consumers can manage the thread-local context dispatch lifecycle without depending on the Vert.x internal API

Motivation

The whole point of VertxContext is to shield consumers from ContextInternal — but until now it only covered context creation (duplicate, nested, etc.), not context dispatch. This forced projects like quarkus-ironjacamar to import ContextInternal directly for beginDispatch() / endDispatch() calls (see DuplicatedContextMessageEndpoint).

The JCA message endpoint delivery lifecycle splits begin/end across separate method calls (beforeDelivery → message delivery → afterDelivery), so the higher-level Context.dispatch(Runnable) API cannot be used. These new methods fill that gap.

Test plan

• Added testBeginAndEndDispatch to both vertx4-context and vertx5-context test suites
• Tests verify that beginDispatch sets the thread-local context and returns the previous one, and endDispatch restores it
• mvn test -pl vertx4-context,vertx5-context passes

[Ladicek]

The whole point of VertxContext is to shield consumers from ContextInternal

Is it? In my eyes, the whole point of VertxContext is to provide utilities for common operations that are not directly available on Context or ContextInternal. (I'm ignoring the whole "nested context" thing, because that should have never existed.)

There's nothing wrong with using ContextInternal, in my eyes.

[cescoffier]

I agree with @Ladicek, I don't think this is bringing much, except exposing low-level APIs which I would not recommend using, except if you know what you are doing.

[gastaldi]

Well, it's explicitly said in the class' Javadoc:

The rationale for this class is to avoid end-users to use the Vert.x internal API.

About @cescoffier's comment, I agree, but I don't see how I can use the recommended Context.dispatch if the spec (eg. MessageEndpoint in JCA) splits into separate methods (same as we do in other core extensions).