Support for ETags in JsServlet

Adds a class to generate and cache ETags, and uses it in JsServlet. Later, we can extend this to other servlets :)

[jtarrio, 2010-12-09 01:28:30]

Optionally invalidate ETags when container configuration changes

[johnfargo, 2010-12-09 01:47:47]

http://codereview.appspot.com/3500042/diff/1/java/gadgets/src/main/java/org/a...
File
java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/EtagHandler.java
(right):

http://codereview.appspot.com/3500042/diff/1/java/gadgets/src/main/java/org/a...
java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/EtagHandler.java:54:
return request.equals(cache.get(etag));
IMO we don't need a tag cache - we only need a consistent mechanism for hashing
output. The cache risks storing a large amount of data, and as well a given
JsUri (or other request key) could yield different results (ie. if JS is
updated).

I'd prefer to see validation logic move to the output stage. For simplicity,
phase #1 can still be JsServlet-only, but the technique is really dead-simple.
All our output is batched anyway, so the additional cost of computing a hash
from JsResponse (or ProxyResponse, etc in future CLs) is fairly small.

To make this generic, I was thinking something like:
1. Introduce ETagHttpOutput class.
  - one method: void emitOutput(HttpServletRequest, HttpServletResponse,
ETaggable);

2. Let ETaggable be an interface exposing InputStream getContent() and String
getETag(). If getETag() is null, compute it as hash(getContent()). This allows
pre-caching of ETag computation, such as in the Proxy server.

You could do away w/ the getETag()/interface idea as well, at least at first.
WDYT?