Prior to this commit, the exists() method in JsonPathExpectationsHelper
correctly asserted that the evaluated JsonPath expression resulted in a
value (i.e., that a non-null value exists); however, if the value was
an empty array, the exists() method always threw an AssertionError.

The existing behavior makes sense if the JsonPath expression is
'indefinite' -- for example, if the expression uses a filter to select
results based on a predicate for which there is no match in the JSON
document, but the existing behavior is illogical and therefore invalid
if the JsonPath expression is 'definite' (i.e., directly references an
array in the JSON document that exists but happens to be empty). For
example, prior to this commit, the following threw an AssertionError.

    new JsonPathExpectationsHelper("$.arr").exists("{ 'arr': [] }");

Similar arguments can be made for the doesNotExist() method.

After thorough analysis of the status quo, it has become apparent that
the existing specialized treatment of arrays is a result of the fact
that the JsonPath library always returns an empty list if the path is
an 'indefinite' path that does not evaluate to a specific result.
Consult the discussion on "What is Returned When?" in the JsonPath
documentation for details:

    https://github.com/jayway/JsonPath#what-is-returned-when

This commit addresses these issues by ensuring that empty arrays are
considered existent if the JsonPath expression is definite but
nonexistent if the expression is indefinite.

Issue: SPR-13351

Prior to this commit, a JsonPath assertion that a path expression
evaluated to an array in JsonPathExpectationsHelper (and therefore
indirectly in JsonPathResultMatchers in Spring MVC Test) would
incorrectly fail if the array was present in the JSON content but empty.

This commit fixes this issue by removing the "not empty" check for
arrays and lists.

Issue: SPR-13320

Issue: SPR-13342

Includes latest dependency updates (Jackson 2.6.1, Jetty 9.3.2, Undertow 1.2.10)

Issue: SPR-13342

Prior to this commit, MockHttpServletRequestBuilder always supplied an
array of cookies to the MockHttpServletRequest that it built, even if
the array was empty.

However, this violates the contract of HttpServletRequest. According to
the Servlet API, the getCookies() method "returns null if no cookies
were sent."

This commit ensures that MockHttpServletRequestBuilder no longer
configures an empty array of cookies in the mock request that it builds.

Issue: SPR-13314

This commit introduces the following methods in JsonPathResultMatchers
in the Spring MVC Test framework.

- isString()
- isBoolean()
- isNumber()
- isMap()

In addition, this commit overhauls the Javadoc in
JsonPathResultMatchers and JsonPathExpectationsHelper.

Issue: SPR-13320

This commit introduces a dedicated build() method in
MockMvcHtmlUnitDriverBuilder to replace createDriver(). In addition,
the configureDriver() method has been renamed to withDelegate() and now
returns the builder for further customization.

This commit also overhauls the Javadoc for static factory methods and
the class-level Javadoc in MockMvcHtmlUnitDriverBuilder for greater
clarity to end users.

Issues SPR-13158

This commit introduces a dedicated build() method in
MockMvcWebClientBuilder to replace createWebClient(). In addition, the
configureWebClient() method has been renamed to withDelegate() and now
returns the builder for further customization.

This commit also overhauls the constructor and class-level Javadoc in
MockMvcWebClientBuilder for greater clarity to end users.

Issues SPR-13158

Some of the HtmlUnit Tests required an internet connection. This
caused failures when running offline.

This commit adds Assume PERFORMANCE to those tests so they are
only ran when the PERFORMANCE group is selected.

Issue: SPR-13158

- formatting
- code style
- organized imports
- precondition assertions
- suppressed warnings
- Javadoc enhancements

Issue: SPR-13158

This commit introduces integration between MockMvc and HtmlUnit, thus
simplifying end-to-end testing when using HTML-based views and enabling
developers to do the following.

 - Easily test HTML pages using tools such as HtmlUnit, WebDriver, & Geb
   without the need to deploy to a Servlet container

 - Test JavaScript within pages

 - Optionally test using mock services to speed up testing

 - Share logic between in-container, end-to-end tests and
   out-of-container integration tests

Issue: SPR-13158

Due to common usage of @Rollback(false), this commit introduces a new
@Commit annotation that more clearly conveys the intent of the code
while retaining the run-time semantics.

@Commit is in fact meta-annotated with @Rollback(false).

Issue: SPR-13279

Issue: SPR-13276, SPR-13277

Since Spring Framework 2.5, @Rollback has been supported on test
methods, with class-level rollback settings configured via
@TransactionConfiguration; however, allowing @Rollback to be declared
on test classes with method-level declarations overriding class-level
declarations would prove more intuitive than having to declare both
@TransactionConfiguration and @Rollback. Furthermore, the
transactionManager flag in @TransactionConfiguration was made
superfluous many years ago with the introduction of support for a
qualifier in @Transactional.

This commit enables @Rollback to be declared at the class level for
default rollback semantics within test class hierarchies and deprecates
@TransactionConfiguration in favor of @Rollback and @Transactional
qualifiers.

Issue: SPR-13276, SPR-13277

Prior to this change, calling the `setDateHeader` method on a
Spring Test MockHttpServletResponse instance would just store the given
long value in a Map, not writing it as a formatted date String.
Also, calling `getDateHeader` on a MockHttpServletRequest would not
support date strings and could not parse those values.

This can be problematic when testing features related to date headers
such as "Expires", "If-Modified-Since", "Last-Modified", etc.

This commit adds formatting and parsing capabilities to Servlet Mocks
for date strings in HTTP headers.

When formatting dates to Strings, the date format used is the one
preferred by the HTTP RFC. When parsing date Strings, multiple date
formats are supported for better compatibility.

Issue: SPR-11912

SPR-13211 introduced support for reusing mock requests in Spring MVC
Test if the request was created by the the Spring TestContext
Framework. Unfortunately, that change makes it impossible for
MockMvc.perform() to be invoked multiple times within the same test
method without side effects. For example, session attributes and
request parameters are transparently and unexpectedly retained for
subsequent invocations of perform(), causing certain categories of
tests to fail.

This commit reverts the changes introduced in SPR-13211 and introduces
a new MockMvcReuseTests class to serve as regression tests within
Spring's test suite.

Issue: SPR-13260, SPR-13211

HTTP headers such as "Expires", "Last-Modified" all use date
strings like "Tue, 21 Jul 2015 10:00:00 GMT". Prior to this commit,
there was no way to match those header values, besides formatting dates
manually.

This commit introduces a new HeaderResultMatcher to test those date
headers using a long timestamp:

```
this.mockMvc.perform(get("/persons/1").header("If-Modified-Since", now))
  .andExpect(status().isNotModified())
  .andExpect(header().dateValue("Last-Modified", timestamp));
```

Issue: SPR-13263

Use ServletHttpResponse.setDateHeader whenever possible and avoid using
SimpleDateFormat.

Prior to this commit, the Spring MVC Test Framework always created a
new MockHttpServletRequest, disregarding any mock request already
present in Spring Web's RequestContextHolder -- for example, one
created by the ServletTestExecutionListener in the Spring TestContext
Framework (TCF).

This commit modifies MockHttpServletRequestBuilder so that it reuses a
mock request created by the TCF. However,
MockMultipartHttpServletRequestBuilder continues to always create a new
MockMultipartHttpServletRequest since a MockHttpServletRequest created
by the TCF is not directly compatible with a
MockMultipartHttpServletRequest. Furthermore, in order to avoid
unforeseen side effects, MockHttpServletRequestBuilder will always
create a new MockHttpServletRequest if a mock request is present in the
RequestContextHolder but not created by the TCF.

Issue: SPR-13211

Issue: SPR-13067

Issue: SPR-13239

When using the Spring TestContext Framework (TCF) to load a
WebApplicationContext and the Spring MVC Test Framework (MockMvc) to
test a controller, two instances of MockHttpServletRequest will be
created. Due to an ordering issue with regard to population of the
RequestAttributes, it is therefore possible that a filter accesses the
mocked request managed by the TCF, while the controller accesses the
mocked request managed by MockMvc, and this leads to test failures if
the controller expects data from the filter to be present in the
request.

This commit fixes this bug by ensuring that the RequestAttributes
backed by the mocked request managed by MockMvc are stored in the
RequestContextHolder before any filters are invoked by MockMvc.

Issue: SPR-13217

This commit adds additional tests to RequestContextHolderTests that
verify proper support for the MockHttpServletRequest managed by Spring
MVC Test in the following scenarios:

- request-scoped service invoked by controller
- session-scoped service invoked by controller
- custom filter that sets request attributes

Issue: SPR-13211

This commit refactors RequestContextHolderTests in preparation for the
work to be done in SPR-13211.

Issue: SPR-13211

This commit introduces a test that verifies the fix introduced in
6842fd7f.

Issue: SPR-13079