* Removed usages of `AbstractConnection.getInvocationType()`.
* Changed HTTP server-side Connection implementations to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `Server`, which derives it from the `Handler` chain.
* Changed client-side receivers to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `HttpClientTransport`.
* Introduced `HttpClientTransport.getInvocationType(Connection)`, so that client applications can specify whether they block or not.
* Made sure client-side HTTP/2 and HTTP/3 return tasks with the proper `InvocationType` to be run by the `ExecutionStrategy` when calling application code.
* HTTP3StreamConnection now uses an `EITHER` fillable callback to possibly process streams in parallel.
* `QuicStreamEndPoint` now uses a task to invoke `FillInterest.fillable()`, rather than invoking it directly, therefore honoring the `InvocationType` of callback set by the `Connection` associated with the `QuicStreamEndPoint`.

Signed-off-by: Simone Bordet <[email protected]>

* Removed usages of `AbstractConnection.getInvocationType()`.
* Changed HTTP server-side Connection implementations to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `Server`, which derives it from the `Handler` chain.
* Changed client-side receivers to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `HttpClientTransport`.
* Introduced `HttpClientTransport.getInvocationType(Connection)`, so that client applications can specify whether they block or not.
* Made sure client-side HTTP/2 and HTTP/3 return tasks with the proper `InvocationType` to be run by the `ExecutionStrategy` when calling application code.
* HTTP3StreamConnection now uses an `EITHER` fillable callback to possibly process streams in parallel.
* `QuicStreamEndPoint` now uses a task to invoke `FillInterest.fillable()`, rather than invoking it directly, therefore honoring the `InvocationType` of callback set by the `Connection` associated with the `QuicStreamEndPoint`.

Signed-off-by: Simone Bordet <[email protected]>

This is the work for the server-side only, the client side will be done in another pull request.

Previously, AbstractConnection.getInvocationType() was called by AbstractConnection.ReadCallback, but it was deprecated and is now removed, along with all its overrides.

This mechanism is now replaced by using a specific Callback implementation for each AbstractConnection subclass.
For example, HttpConnection uses HttpConnection.FillableCallback that in turn asks the InvocationType to the Server, and therefore the `Handler` tree.

Restored synchronous code for ServerFCGIConnection.close(), ensuring super.close() is always called.
Ensuring that in HttpConnection.close(), super.close() is always called.

Signed-off-by: Simone Bordet <[email protected]>

This is the work for the server-side only, the client side will be done in another pull request.

Previously, `AbstractConnection.getInvocationType()` was called by `AbstractConnection.ReadCallback`, but it was deprecated and is now removed, along with all its overrides.

This mechanism is now replaced by using a specific Callback implementation for each `AbstractConnection` subclass.
For example, `HttpConnection` uses `HttpConnection.FillableCallback` that in turn asks the `InvocationType` to the Server, and therefore the `Handler` tree.

Introduced `AbstractConnection.NonBlocking` for the cases where `onFillable()` is non-blocking.

Restored synchronous code for `ServerFCGIConnection.close()`, ensuring `super.close()` is always called.
Ensuring that in `HttpConnection.close()` `super.close()` is always called.

Fixed promise notification to avoid race between the task (writing an error response) and the promise (resetting the stream) in HTTP/2 and HTTP/3.

Signed-off-by: Simone Bordet <[email protected]>
Co-authored-by: Greg Wilkins <[email protected]>

This is the work for the client-side.

Now the `InvocationType` can be specified at the `HttpClientTransport` level, or at the `ClientConnectionFactory.Info` level (for the dynamic transport).

Wired the `InvocationType` also for `Response.ContentSourceListener`, so that for applications that read response content using `Content.Source` and specify an `InvocationType` to `demand(Runnable)`, the implementation will honor it.

Signed-off-by: Simone Bordet <[email protected]>