ContainerRequestContext setRequestUri breaks UriInfo getBaseUri

This is a follow-up to RESTEASY-1050 but at a higher level (i.e. not "what you should have done", but what actually breaks with the current implementation).

setRequestUri (either flavor) will compute a new getBaseUri by stripping the path of the new getRequestURI. This leads do:

• broken links when you construct them with uriInfo.getBaseUriBuilder().path(SomeRootResource.class).build()) and your application base URI is supposed to have a non-empty path
• broken resource matching when using the 2-args flavor. E.g. if you have a resource at /bar and use setRequestUri("/foo/", "/foo/bar") (pseudo-code), you'd expect the "application-specific request URI part" to be resolved as /bar (relative to a base URI of /foo) and match your resource, but it's actually resolved as /foo/bar (relative to a base URI of /) and fails to match your resource.

The way the base URI is computed, it also keeps the query parameters from request URI, which makes it dependent upon the request URI and unusable as-is as an invariant between requests. While the spec is not explicit about this, I'd expect the base URI to never contain query or fragment parts.

FYI, my use-case is implementing a filter that reads a X-Forwarded-Proto set by a reverse-proxy and conditionally calling setRequestUri with the base and request URIs rewritten with an https scheme:

if ("https".equalsIgnoreCase(requestContext.getHeaderString("X-Forwarded-Proto"))) {
  requestContext.setRequestUri(
      requestContext.getUriInfo().getBaseUriBuilder().scheme("https").build(),
      requestContext.getUriInfo().getRequestUriBuilder().scheme("https").build());

My "initial" base URI doesn't have a path part so I'm not affected by the first issues listed above, but I want to use the base URI as an "iss" in a JWT used for OpenID Connect, and it currently contains the query params which later breaks code that validates the "iss" (e.g. the OpenID Connect "end_session_endpoint" validating the id_token_hint). Fortunately, the workaround is easy: use getBaseUriBuilder().replaceQuery(null).build() instead of getBaseUri().