Prevent race condition when using requests_futures and ThreadPoolExecutor

[phodge]

When using requests_future.Session and a ThreadPoolExecutor there is a race condition where one thread removes the monkeypatched session.get_adapter() method before another thread has finished using it. This results in the losing thread mistakenly using the real requests adapters and likely executing a real http request.

This PR wraps the monkeypatching logic in a threading.Lock to prevent multiple requests racing either other.

Given that other session methods are monkeypatched it's possible there are other race conditions in threading contexts, but making requests_mock completely thread-safe is beyond the scope of this PR.

[ticosax]

This PR is working for us. Thanks

[phodge]

Hi @jamielennox, is there anything I can do to help get this PR merged into a new official release? For the last 8 months I've been using my own fork on github but this has numerous issues, one of them being that pip takes longer to install this one package from github than installing all of my other dozens of requirements combined. I'd much rather help you improve this package than start a permanent fork.

[jamielennox]

I'm sorry, this shouldn't have gone so long without a release. I've need this and I'll do a few small fixes and cleanup to do a release this week.

Thanks for the prompt and sticking with it.