Crowd Rest Client always uses absolute url when revalidating http request

Quoting from CONFDEV-27506:

One of the fancy new features of Crowd 2.8 is a switch to httpcomponents so we can take advantage of caching (the cookie config resource above is the most commonly used REST resource in Crowd, and all it does is answer "what should the sso cookie be called?").

The caching layer (httpclient-cache) serves cache hits from its cache and transparently passes through to the normal httpclient for cache misses - so far so good.

The tricky bit comes when a cache is hit but the cache has expired: then httpclient-cache fetches the request from the cache, looks at it, but realises it's no longer a valid response according to the caching rules. So then it passes it back through to the underlying httpclient to fetch the response from the server ("revalidates it"), and caches that again, and sends it back. Still good.

The bug is that httpclient rewrites requests to make the URI relative (org.apache.http.impl.execchain.ProtocolExec#rewriteRequestURI - storing the original request as an attr of the new request), but httpclient-cache bypasses this part of httpclient's code when it does the revalidation of an expired cache hit because it constructs a new request from the original request stored in the cached request (which is stored in the cache too).

And Apache in OnDemand returns a 400 response for any request with an absolute URI.

Upstream bug: https://issues.apache.org/jira/browse/HTTPCLIENT-1542