Prior to this commit, when adding a ShallowEtagHeaderFilter to an
application, the ServletResponse would be wrapped by a
ContentCachingResponseWrapper. When any part of the Spring
infrastructure calls `flushBuffer` on the wrapped response, the call is
delegated to the actual response, which is committed. It's not possible
to alter the response (headers, content) anymore - the ETag filter can't
act.

This change prevents the `flushBuffer` call to be delegated and only
commits the underlying response once the cached content is copied to the
actual response stream.

Issue: SPR-13717

Issue: SPR-13563

Issue: SPR-13004

Remove unused imports

Issue: SPR-12960

Prior to this change, the ShallowEtagHeaderFilter would use a
ResizableByteArrayOutputStream to internally write data and calculate
the ETag. While that implementation is faster than the regular
ByteArrayOutputStream (since it has a better strategy for growing the
internal buffer), a lot of buffer copying/writing still happens.

This change adds a new FastByteArrayOutputStream implementation that
internally uses a LinkedList<Byte[]> to store the content. So when
writing bytes to that OutputStream implementation, new byte[] are
added to the list when the previous ones are full. This saves most
of the instantiating/copying operations.

Note that new methods were added in DigestUtils to allow usage of
Streams instead of byte[], which is more efficient in our case.

Fixes #653

Issue: SPR-12081

ShallowEtagHeaderFilter writes body early on sendError/sendRedirect and interprets setContentLength/setBufferSize as a hint for capacity increase

Issue: SPR-11705
Issue: SPR-11717

Prior to this commit, all 2xx HTTP responses were eligible for ETag
generation in ShallowEtagHeaderFilter. In some cases, this would use
CPU resources for no reason since HTTP clients would not use ETags.

This commit is an optimization and restricts ETags generation in cases
where (all conditions must be met):
- response has a 2xx status
- request is a GET
- response does not contain "no-store" in its "Cache-Control" header

Issue: SPR-11110

Issue: SPR-10129

Previously when running the tests for spring-web, spring-webmvc,
spring-test-mvc, and spring-orm there were possible collissions in the
classpath due to the fact that each had its own copy of the web.Mock*
classes in it. This causes uncertainty for which class the code was
running against. Furthermore, the maintance of keeping the copies up to
date was tedious.

Now there are two copies of the web.Mock* classes. The ones that exist
in spring-test main sources and a copy that supports servlet 3 within
spring-web test sources. The copy in spring-web test sources has been
moved to a new package to avoid having the classes exist twice on the
classpath within Eclipse.

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories

In accordance with recommendations at
http://www.apache.org/licenses/LICENSE-2.0.html.

A number of classes had strayed from this format, now all
are the same.