Prevent Content-Length and Host headers from being copied by default

[jkuipers]

This PR introduces an additional property to skip copying certain headers from the incoming request.
Because the use case is different, it's bad to force users to add headers like Host and Content-Length to the list of sensitive headers when they need to override that (e.g. for adding smth like an X-APIKey header), so having a separate configuration setting for this is preferable.

Fixes gh-3154

[spencergibb]

I've added back removed/renamed fields and methods as we can't have breaking changes outside of a major. See b30188e

[artemkutishevsky]

Hello @spencergibb @jkuipers,

Just wanted to let you know that a breaking change still was introduced here. "Host" and "content-length" headers were not treated in any special way before those two commits and now they are excluded by default. Which results in a failure of course if someone relies on the "host" header being set for example.

[jkuipers]

Hello @spencergibb @jkuipers,

Just wanted to let you know that a breaking change still was introduced here. "Host" and "content-length" headers were not treated in any special way before those two commits and now they are excluded by default. Which results in a failure of course if someone relies on the "host" header being set for example.

The RestTemplate (or rather its underlying HTTP client, in case of the host header) should set those values itself to the values appropriate for its own request. It makes no sense to copy these headers from the original request, since they can/will be wrong (host is almost always wrong, the content-length case is described in this issue in detail).
This is indeed different from the old behavior, but the old behavior wasn’t a feature but a bug as far as I’m concerned.