5.0 - Slightly rework the limit algorithm APIs to always return decision outcomes

[tjquinno]

Helidon Version: 5.0

Task Description

In 4.x we added methods to the LimitAlgorithm API so callers could become aware of the outcome of the algorithm's decision, even if no Token was returned. In 4.x a token is returned when the limit algorithm decides that the work should proceed, based on the concurrency limit settings. But until some enhancements in 4.3, the caller could not find out other information about the outcome (was it deferred? if so, when did the wait in the virtual queue start and end?)

To maintain backward compatibility with possible non-Helidon implementations of LimitAlgorith we kept the old signatures and provided default implementations for the new signatures. As a resist. it would be possible for callers of the new methods to ask to be told of the outcome of the decision but the underlying limit algorithm implementation would not oblige because it did not itself implement the new signatures.

We should change the LimitAlgorithm API in a non-compatible way so that every method returns a LimitOutcome (instead of returning the current Optional<Token>).

The LimitOutcome.Acceptedsub-interface (added in 4.3) would have a method which returns a Token; it should not be Optional because the Accepted subtype is returned only if the work was accepted, so of course there will be a Token.

As in 4.x, the caller would invoke methods on the Token (if it was provided) to indicate the ultimate execution result of the work.