Embed kerberos auth handler

[nitzmahone]

The requests-kerberos auth handler pywinrm relies on for Kerberos auth is going to remove functionality needed by pywinrm for HTTP message encryption (see requests/requests-kerberos#133) in order to fix some concurrency issues when using requests-kerberos from multiple threads with a shared session object.

Rather than scrambling to adapt pywinrm to the (still unproven) method being proposed over on requests-kerberos, I'm suggesting that we embed a copy of requests-kerberos locally. We could also either just switch over to requests-gssapi or embed a copy of that and use python-gssapi directly, but we'd have to keep some form of the old stuff around to support Windows clients anyway (since python-gssapi didn't support Windows last I checked).

@badcure @jborean93 this is a fairly major storm headed our way, so we'll need to act quickly before requests-kerberos does a release, or everyone's going to be broken... Thoughts?

[badcure]

👍 to a copy of requests-kerberos. I think that would be the path with the least moving parts, since this changes is coming soon. Reading up on the issue now(i.e. wrapping my head around it).

[jborean93]

I'm good for having a copy, ultimately it would be nice to move away from pykerberos/winkerberos to python-gssapi and pywin32 but that would be a change further down the track when we aren't pressed for time.

[nitzmahone]

OK cool- I'll try to whip up a PR today that embeds it and updates the kerberos extras_require section to do the right thing. Thanks for the feedback.

[frozencemetery]

When you say "support Windows", do you mean: supports Windows using the SSPI, or supports Windows users who install MIT Kerberos for Windows? (We're in the process of merging the second one: pythongssapi/python-gssapi#177 )

[jborean93]

@frozencrmetary, would be the former using SSPI. Currently requests-kerberos works over Linux and Windows which we need to continue.