Add requested URI discovery support

[tjquinno]

Resolves #5826

Intro

Forwarded and X-Forwarded-* header support allows code that processes requests to obtain, to the best of Helidon's ability, the URI information as specified by the original client even if the request passed through proxies from the original client to the Helidon service.

The feature adds two main outward interfaces to Helidon:

1. Developers or deployers can control various settings on each socket which govern the behavior of this feature:

   • enabled/disabled
   • which proxies to trust (uses the new AllowList)
   • the priority of checking Forwarded vs. X-Forwarded-* vs. Host headers.

   In 4.x, the RequestedUriDiscoveryContext interface embodies these settings (in helidon-common-configurable along with its implementation), assignable via config or builders.

2. The ServerRequest interfaces (one in Níma, one in reactive) now declare the UriInfo uriInfo() method so developer or Helidon code working with requests can obtain the requested URI information as specified by the original client.

The logic for building this new UriInfo record is in the new utility method RequestedUriDiscovery.uriInfo (in helidon-common-http).
This method accepts neutral (not specific to either Níma or reactive) information about the request and an instance of the new RequestedUriDiscoveryContext interface.

Because RequestedUriDiscoveryContext is an attribute of each socket, the server request implementation classes need a way to get the relevant socket information.

In Níma

The key ServerRequest implementations are Http1ServerRequest (helidon-nima-webserver) and Http2ServerRequest (helidon-nima-http2-webserver). Both already have a reference to ConnectionContext (helidon-nima-webserver).

The ConnectionContext interface extends interface SocketContext (in helidon-common-socket although it is used only by Níma, not reactive) to reflect the socket settings.

Adding RequestedUriDiscoveryContext requestedUriDiscoveryContext() to SocketContext (and its impls) therefore makes the discovery context available to the server request implementations.

SocketContext is also implemented by the PlainSocket class (which the class TlsSocket extends) and DirectSocket,
so these impls of SocketContext need to implement requestedUriDiscoveryContext():

• ConnectionContextImpl
• PlainSocket
• DirectSocket (in helidon-nima-testing-junit5-webserver)

which means their constructors/factory methods/builders need to change as do the callers of those constructors/factory methods/builders:

• PlainSocket#server (invokes PlainSocket#<init>
• ServerListener (invokes PlainSocket#server and TlsSocket#server)

In reactive

The key ServerRequest impl is the abstract class Request (helidon-reactive-webserver).

That class already has a reference to BareRequest to which this PR adds a getter for its SocketConfiguration (interface in helidon-reactive-webserver).
The constructor for BareRequestImpl now accepts and stores the SocketConfiguration which the added getter method returns.

FoprwardingHandler (helidon-reactive-webserver) already has a reference to the SocketConfiguration so now it passes that as an additional parameter when it invokes the BareRequestImpl constructor.

This PR also changes SocketConfiguration:

• Adds RequestedUriDiscoveryContext requestedUriDiscoveryContext()
• To its inner interface SocketConfigurationBuilder:
  • Adds setter and getter for RequestedUriDiscoveryContext.Builder
  • Updates config to handle discovery context

Also, the PR updates the impls of SocketConfiguration and SocketConfigurationBuilder accordingly.

Other

There are some other changes to unrelated test classes, adding new required methods.

Depends on #6109

new sheriff in town