Introduce versions of ClientRequestFilter and ClientResponseFilter that can suspend and resume

[geoand]

Description

In RESTEasy Reactive we have the ResteasyReactiveContainerRequestFilter and ResteasyReactiveContainerResponseFilter which can suspend and resume thus allowing for non-blocking filters.

We should have something similar for the client

Originally came up in #16523

[quarkus-bot]

/cc @FroMage, @stuartwdouglas

[FroMage]

Well OK, but then also exception mappers, no? ;)

[geoand]

Yup

[geoand]

But probably later, cause I don't know if/how are handling the exception mapper for the client

[FroMage]

Sure, those are not linked.

[geoand]

I opened a new issue: #16626

[FroMage]

Damnit, man, I'm sorry I misread this issue. I thought you were talking about annotation-declared client requests and filters, and I suggested adding annotation-declared exception mappers. I didn't realise I had mis-read the subject. I don't think exception mappers can suspend on the server-side, can they?

[geoand]

No need to apologize, you likely read the correct thing :)
What happened is that when I opened the issue initially, I did mention the annotations. Howeve then I realised that the client doesn't automatically register filters, so I then changed the title and description to only mention suspend and resume.

As for exception mappers, they can resume on server

[FroMage]

Hahahaha, excellent :)

[FroMage]

However then I realised that the client doesn't automatically register filters

Huh, is that by design or because we forgot?

[geoand]

I think it's just how the JAX-RS client works by spec - if it worked otherwise, the TCK would have a ton of failing tests :)

[FroMage]

I think it's just how the JAX-RS client works by spec - if it worked otherwise, the TCK would have a ton of failing tests :)

OK, but is it what we think is the right thing to do?

I mean, programmatically supporting them is one thing, and we do ATM. But why limit it this way?

https://quarkus.io/specs/jaxrs/2.1/index.html#binding_in_client_api says:

Binding in the Client API is accomplished via API calls instead of annotations. Client, Invocation, Invocation.Builder and WebTarget are all configurable types: their configuration can be accessed using the methods inherited from the Configurable interface. See Configurable Types for more information.

So, IMO we can make a good case for supporting, in addition to the spec, globally registered client filters by adding @Provider on them, or with new annotations like @ClientRequestFilter

[geoand]

Yeah, I like the idea.
Up until today I actually thought that the filters where automatically registered