Don't include kwargs of request() in the body of auto refresh request

[east825]

Extra key-value pairs of the request body should be supplied using
the dedicated auto_refresh_kwargs attribute of the session object.

Meanwhile, several common parameters of request() and refresh_token()
are propagated to the latter, since, otherwise, auto refresh request
might end up without some critical connection parameters such as proxy
mapping.

[Lukasa]

Before we go any further, is there a reason to prefer this PR to that in #265?

[coveralls]

Coverage increased (+0.03%) to 87.636% when pulling dc57b27 on east825:master into f98e7bd on requests:master.

[east825]

@Lukasa Yes, it addresses the same issue, but I have some doubts about its backward compatibility. Just wanted to share a simpler approach to fix some of the problems with auto refresh.

[Lukasa]

Yeah, so I can understand that train of thought. However, this patch also subtly violates backwards compatibility, so my inclination is to go with the solution that advertises itself to users a bit more. Does that make sense?

[Lukasa]

Didn't mean to close that, I'm apparently having a bad day for clicking on the correct buttons.

[coveralls]

Coverage decreased (-0.2%) to 87.419% when pulling dc57b27 on east825:master into f98e7bd on requests:master.

[coveralls]

Coverage increased (+0.03%) to 87.636% when pulling dc57b27 on east825:master into f98e7bd on requests:master.

[coveralls]

Coverage increased (+0.03%) to 87.636% when pulling dc57b27 on east825:master into f98e7bd on requests:master.

[coveralls]

Coverage increased (+0.03%) to 87.636% when pulling dc57b27 on east825:master into f98e7bd on requests:master.

[east825]

my inclination is to go with the solution that advertises itself to users a bit more. Does that make sense?

Sure, all of a sudden I also realized that my approach with propagation of parameters like timeout and proxies to refresh_token() is additionally error-prone, because, in general, OAuth provider and protected resource accessed via REST API can be entirely different servers with different connection settings.

Except for that ambiguity regarding the names of auto_refresh_kwargs, I agree that the solution from #265 is indeed more comprehensive and flexible. Feel free to close this PR.

[Lukasa]

Thanks for the work!