Fix android domain dot prefix bug

[luke-cramer]

What's wrong?

Important

Currently, there is no way to set a cookie without a . prefix which can lead to buggy behavior with some sites.

This PR fixes that, by allowing cookies to be set without a domain and instead inferred from the url. Domain is allowed as an optional value in the Android CookieManager docs when setting a cookie.

Example usage of Cookiemanager.set which should result in a . domain prefix vs not:

// Setting a cookie like this should result in a `.` prefix in chrome dev tools
// This indicates it include sub-domains
CookieManager.set('www.example.domain.com', {
  name: 'Foo',
  value: 'Bar',
  domain: 'example.domain.com', // or '.example.domain.com'
});
// Cookie in chrome dev tools correctly results in: '.example.domain.com' 

// Setting a cookie like this should NOT result in a `.` prefix in chrome dev tools
CookieManager.set('www.example.domain.com', {
  name: 'Foo',
  value: 'Bar',
  // no domain specified
});
// Currently results in: '.example.domain.com'
// After PR results in: 'example.domain.com'

This proposed change removes topLevelDomain as a fallback value when domain is missing. This indirectly allows setting a cookie without a . prefix in android, more info about the leading dot and how the dot infers hostOnly.

Why is this an issue?

Important

Currently, a cookie Foo can be duplicated on android because of the . domain prefix and there is no way to set a domain without a . prefix via the react-native-cookies library

For me, this caused a re-direct loop in one of our webviews because the site was only looking at the original cookie value and not the duplicated cookie value which was set by the HTTP response. I imagine the buggy behavior could manifest in different ways as well.

How to reproduce?

1. Set a Foo=Bar cookie via CookieManager.set()
2. Set a Foo=FooBar cookie via Set-Cookie response header in a Webview on android.
3. The result is two cookies with the same name, but different domains which are both valid cookies according to RFC 6265.

Additionally, you can quickly verify that this is possible by simply creating two cookies in chrome dev tools.

[Beat-YT]

We can also use CookieManager.setFromResponse no?
I find that CookieManager.set isn’t working really good