[idea] Change how we merge request and session settings

Problem

Currently, tools (e.g., openstack/python-swiftclient) fight how requests sets the Content-Type header for a request. Notice that if the user of swiftclient doesn't provide their own content_type then the library sets the header's value to ''. Ideally, setting None in a situation like this (where the Session has no default Content-Type) would prevent the request preparation from setting its own Content-Type header. This doesn't work because the per-session and per-request settings are merged at the session level.

Potential solutions

Split the responsibility of merging settings

The merge at the session level could just take care of ensuring that the per-request settings have priority while waiting for the request preparation to remove Nones. The downside of this behaviour is that it breaks backwards compatibility. Why? Consider the following:

import requests

s = requests.Session()
s.headers['Content-Type'] = 'application/json'
s.post(url, data={'some': 'formdata'}, headers={'Content-Type': None})

This allows for requests to detect that it is in fact application/x-www-form-urlencoded by removing the default set by the session. Keeping backwards compatibility would mean that we would have to do extra work while merging settings on the session-level. We would have to check if the header was set on the session level, and then we would delete headers with value None, otherwise, persist the None value. This is clearly a lot of extra logic.

Create a constant/singleton to mean "Do not autogenerate any of this for me"

We could potentially expose a new constant or singleton in requests to allow users to specify when they want to prevent requests from handling it for them. I dislike this idea a lot, but it's potentially easier to implement and a bit more explicit than overloading the already overloaded meaning of None in this context.

Start with the session-level settings merge linked in requests/sessions.py, then trace request preparation and the swiftclient Content-Type example described here. The issue presents competing designs but chooses neither, so first establish the intended None behavior and its backward-compatibility requirements before defining tests and completion criteria.