Jetty 12 - New HTTP Cookie interface

[gregw]

This PR replaces the HttpCookie class with an interface, that allows us to facade the servlet API cookies to our API, rather than copy over the state.
Furthermore, this also embraces the "everything is an attribute" approach taken by the servlet API cookies, so we no longer have the difference in the attribute sets from a standard cookie vs our own cookie. This greatly reduces (but not eliminates) the copying of attribute maps.
Also, the hacks for extracting attributes from comments have been moved to be ee8/ee9 only

[joakime]

I like the direction this has taken, the HttpCookieFacade makes is clear how powerful this approach is.

The API could use some tweaking (builder please).
The Test case could use some cleanup to avoid setting map entries for those things that are defaulted already.
Other nits around typos, etc.

[sbordet]

I'd like to chime in with a client-side view about this PR.

I like HttpCookie becomes an interface, would be easier to have an implementation based on java.net.HttpCookie, if necessary.

However, it has become clunky to use, as it is quite common for a client to specify domain, path, expirations for "hardcoded" cookies to send to the server.
For example:

HttpCookie cookie = new HttpCookie("foo", "bar");
cookie.setDomain("domain.com");
cookie.setPath("/");
cookie.setMaxAge(TimeUnit.DAYS.toSeconds(1));

httpCookieStore.add(uri, cookie);

IIUC, now the API is just from(name, value, Map), but I would prefer a builder-style API like HttpURI as in:

HttpCookie.from(name, value).domain("domain.com").maxAge(-1).path("/path").build();

Also, there is a little mess with regards to the client-side HttpCookieStore, which is currently in jetty-util and not in jetty-http where it should be.
However, it is currently an implementation of java.net.CookieStore, which again ties us to the JDK implementation as in particular it store/returns java.net.HttpCookie instances.

So I'm proposing to ditch that class and write a oej.http.HttpCookieStore interface and implementation based on our own HttpURI and HttpCookie instead of JDK classes, so if we need to change something we can (for example, the JDK implementation does not do path matching like it is supposed to, so the client needs to do a double pass at filtering the cookies to send for every request).

Thoughts?

[joakime]

Lots of good here.

Small change of a name of constant left

[sbordet]

Also, CookieCache and CookieCutter can probably be united into CookieParser (a better name for CookieCutter?

[gregw]

@sbordet if the client needs a fluent interface, then we can easily add one. But can it be done in a different PR rather than keeping this one unmerged for even longer?

Only issue is the class with the from name, but elsewhere we have used build so we can easily add:

    HttpCookie cookie = HttpCookie.build("name","value").domain("domain.com").maxAge(-1).path("/path").build()

But I'd like to do that in a PR that actually used it, i.e one that does changes to the client.

[gregw]

@sbordet again I think changes to CookieCutter should be in a different PR, especially if there is going to be work done on adding a cookie store to the client.