[WIP] Add a custom requests cookie policy

This ensures that we follow RFC 6265 Section 4.1.2.3 appropriately. If a
cookie is returned without a domain attribute, we do not want to send it
to subdomains.

Closes #2576 

---

Needs:
- [ ] Tests
- [ ] Documenting this breaking change
- [ ] Porting to requests-toolbelt for early adopters
- [ ] Backport to master for a 2.x release


Actually, this isn't right. We probably need to just override `return_ok_domain`. This is too soon, since we only care about this for subdomains.


Heh, I was just about to leave a code review comment to that effect until I saw your comment. This is definitely WIP, we should tag it as such. =)


Yep. After spending too much time in the weeds in cookielib, I used the solution that worked at first and then realized it was wrong and went to bed.


So I can easily add tests around this at this point. I don't think we need to test that the stdlib handles options appropriately. I did a quick test with the "server" provided in the bug report. That said, I think we can provide the function to create our new default policy without using it by default in 2.x I don't think we need to use the toolbelt for this.

We can document that by default we will be using strict domain policy in 3.x and that we will be setting the policy by default. People should start using the new policy as soon as possible. Making it available in requests now makes it a `__future__` like feature.

I guess if we want people with versions older than 2.x.0 (where x is the version in which we include this function) we can put it in the toolbelt too. 


Yeah @sigmavirus24, I'd like to do that too.


@Lukasa so this breaks some of our tests around cookies. Particularly because HTTPbin doesn't set the `domain` attribute. So we at least know this works as intended. I'll see how difficult it would be to fix this in httpbin


While I was falling asleep I realized that this _shouldn't_ be breaking our tests since we're not using a subdomain. That makes me think I chose the wrong strict domain option. We're may still need to rewrite that logic regardless. This may also be a bug in the standard library


So this isn't breaking tests the way I thought it was. When I looked at which tests are failing, I noticed what was happening. The tests in question all do roughly the following:

``` py
requests.get('https://httpbin.org/get', cookies={'foo': 'bar'})
```

In other words, we're expecting a `Cookie` header to be sent that looks like `Cookie: foo=bar` to that URL. This fails because those cookies are naively added to a Cookie Jar and that cookie has no domain associated with it which causes it to not match the request host.

This makes me ask some questions (since I rarely use cookies like this):
- Do users actually use cookies like this?
- Can we safely assume that cookies like this are always meant for the host, e.g., unless the cookie is parsed to have a domain, we forcibly set it to our request host for that request?

Further this also affects users who do something like:

``` py
s = requests.Session()
s.cookies['foo'] = 'bar'
s.get('https://httpbin.org/get')
```

This, however, is far more nebulous. There is no good way to know what domains to send that cookie for. Previously we did something that was arguably really really awful (send it for all domains, I suspect). I think this begs, then, for a helper to create a cookie to be used here. Thoughts @Lukasa?


Ugh. Cookies are terrible. All is forgiven, PHK. All is forgiven.

Yeah, the only _consistent_ behaviour while we allow that API is to send those cookies to all hosts. I have no idea how we're going to make that work with cookielib as it stands.


Okay, so @Lukasa and I discussed this in [IRC](https://botbot.me/freenode/python-requests/2015-08-15/?msg=47298372&page=1). The result was the following:
1. Continue with this as it is
2. Update `create_cookie` helper to **require** a domain attribute
3. Disallow string-ish types (str, unicode, bytes, etc.) when assigning to a CookieJar (e.g., the case where you update a session's cookies by doing `s.cookies['foo'] = 'bar'`). This will mean only accepting Cookie objects as the value. (We may also want to validate that said cookie has a domain attribute, or at least issue a warning if it does not.)
4. When passing `cookies=` to a request method, **assume** that if a domain isn't present, it is explicitly for the request domain.

What does this mean for the backport to the `requests-toolbelt` and 2.x:
1. The toolbelt will start to carry the re-implementation of the CookieJar from this request when we move this functionality there.
2. The toolbelt will also carry the implementation of `create_cookie` that **requires** a domain
3. requests 2.x will start issuing a `DeprecationWarning` when doing `s.cookies['foo'] = 'bar'` to warn people of the change coming in 3.0
4. requests 2.x will carry this policy function that's already written so people can start using it and seeing how their code may break but only if they opt in by creating a Policy and a new Cookie Jar with that policy.


Ugh so this also affects `cookiejar_from_dict`.


@Lukasa @sigmavirus24 what is the status of this? I was working a bit in the `RequestsCookieJar` code for #3028, and I'd be willing to work on this a bit if it's still something you think should move forward.


@davidsoncasey this is not a simple change. I have a lot of work locally that I'm not yet ready to push.


Closing due to inactivity (not sure if that's our fault or not, sorry!). Please re-submit if you're still interested in contributing this code :)