Add CharSequence overloads for putHeader methods in HttpRequest

[Vynbz]

Motivation

As discussed in #2770, the HttpServerResponse interface in vertx-core already provides CharSequence overloads for header methods, but the web client's HttpRequest interface only accepts String parameters. This inconsistency means users need to convert CharSequence values (like Netty's HttpHeaderNames constants) to Strings unnecessarily.

[Vynbz]

While putHeader(CharSequence, CharSequence) works fine, adding putHeader(CharSequence, Iterable<CharSequence>) causes ambiguous method call errors with existing code. Should I proceed with just the single-value overload, or would you prefer a different approach?

[tsegismont]

@Vynbz thanks for the PR.

[tsegismont]

Can you create a default implementation that converts to String?

[Vynbz]

I've updated the implementation to use interface default methods as you suggested

[tsegismont]

While putHeader(CharSequence, CharSequence) works fine, adding putHeader(CharSequence, Iterable<CharSequence>) causes ambiguous method call errors with existing code. Should I proceed with just the single-value overload, or would you prefer a different approach?

Please go ahead and add the method. You can update WebClientTest for ambiguous method calls.

[tsegismont]

Thanks for the updates @Vynbz

In fact, I was suggesting to add default implementations, so that existing implementations in other projects don't break with the new release.

But in our project, we must implement these new methods in an efficient manner (always converting to string defeats the original purpose of this PR)

[Vynbz]

@tsegismont thanks for review

Just to make sure I understand correctly before I push the changes - you want me to keep the default implementations in the HttpRequest interface, but also keep efficient override implementations in HttpRequestImpl that pass the CharSequence directly to headers().set() without converting to String?

Also regarding the tests, I've updated them to handle the ambiguous method calls by adding CharSequence cast - is this the right approach?

[tsegismont]

@tsegismont thanks for review

Just to make sure I understand correctly before I push the changes - you want me to keep the default implementations in the HttpRequest interface, but also keep efficient override implementations in HttpRequestImpl that pass the CharSequence directly to headers().set() without converting to String?

Exactly

Also regarding the tests, I've updated them to handle the ambiguous method calls by adding CharSequence cast - is this the right approach?

Yes

[Vynbz]

@tsegismont Done! Changes implemented as discussed and commits squashed