Description
While refactoring the unix domain socket implementation in #228, I noticed that redirects likely haven't been checking URL schemes correctly for some time now, or I'm not completely following the logic and intended use of RedirectHandler.
My assumption is that RedirectHandler.redirectTarget(status:, headers:) validates the incoming header, and returns a URL to redirect to if it passes all the necessary checks.
If I'm right, that means that the redirect logic checks the current request rather than the new URL to see if it can redirect to it - this likely never worked as designed due to the fact that it would always pass, since we have a request that is already valid, and we are checking it once again for validity...
It's also likely that this check never worked, but redirects to foreign URLs were still possible, since creating the Request later in the process would eventually fail, but there are no checks to ensure the Request hasn't been redirected from a host-based server to a socket based one, so something is still fishy in that regard.
If my assumption isn't misguided in some way, I suggest we refactor the check for the scheme as follows:
The new supportsRedirects(to:) method (refactored, since it is only being used in this scenario now):
Additional tests should clarify if this is working as designed or not.