Revisit encoding/decoding implementation

[carhartl]

Our RFC 6265 based cookie name + value encoding was based on the
requirements for server implementers, and as such too strict.

We need to look at RFC 6265 section 5.2, requirements for user agents.

But even the algorithm described in section 5.2 isn't that relevant
for us, in that we had to follow the steps when writing a cookie with
this library. This is left to the browser vendors who have to implement
the setter functionality behind document.cookie. All we have to do is
avoid surprises when said algorithm is being followed while
document.cookie = ... is being executed with the cookie string we're
constructing.

It means we have to encode ";" and "=" in the cookie name, and ";" in
the cookie value.

Follow-up to discussion in #595.

Closes #590, #595.

Open question: should we be liberal in what we accept/read, that is apply decodeURIComponent() to the cookie value, in case we get a server-side written cookie that adheres to RFC 6265? Since we will use percent encoding for ";" in the value we could support that without a lot of effort. An advantage might be that this way we'd be reading v2 cookies without a problem, making the transition from v2 -> v3 not require a cookie migration. Or would we leave that to the user who would have to implement a converter for a complete percent decoding?

The upside is that we're again well-below 700kb for the gzipped size of the library.

PS: I would probably also want to rename the "rfc6265" converter to something else now as part of this... basically they're semicolon converters now.

[carhartl]

Should we be liberal in what we accept/read, that is apply decodeURIComponent() to the cookie value when reading, in case we get a server-side written cookie that adheres to RFC 6265?

Wrong! Same mistake again. This is making the assumption that servers adhering to RFC 6265 would use percent-encoding to encode the forbidden characters mentioned in the spec, but the spec doesn't say anything about how those characters should be encoded. It mentions Base64 in fact:

servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64

[carhartl]

So.. we are going to apply the minimal encoding/decoding, for everything elseinteroperability with servers we are providing converters.

[carhartl]

I have no idea why the pr check fails in Travis, while the one for push passes...

[FagnerMartinsBrack]

Need to verify if SERVER_SIDE.md fixes still hold true

[FagnerMartinsBrack]

The upside is that we're again well-below 700kb for the gzipped size of the library.

Can change the README to < 700 bytes gzipped then! It's currently < 800 bytes gzipped :D

[carhartl]

Need to verify if SERVER_SIDE.md fixes still hold true

I looked at these and I think so.. or they've been wrong even before these changes here: for instance what confused me was that the docs suggest to escape parens for Tomcat:

var TomcatCookies = Cookies.withConverter({
  write: function (value) {
    return (
      Cookies.converter
        .write(value)
        // Encode the parens that are interpreted incorrectly by Tomcat
        .replace(/[()]/g, escape)
    )
  },
  read: Cookies.converter.read
})

But the default converter was percent-encoding ( and ) anyway. Ok, it wasn't. I thought it was because cookie-name is a token according to RFC 6265, where ( and ) are not allowed - so it seems we were even missing something in our earlier encoding implementation.