Spring Multipart request support in MockRestServiceServer

Introduce MultipartFormDataRequestMatchers for MockRestServiceServer. Handles ONLY multipart/form-data requests.

E.g.

MockRestServiceServer mockServiceServer = MockRestServiceServer.createServer(restTemplate);
MultiValueMap<String, Resource> filesMultiMap = new LinkedMultiValueMap<>();
filesMultiMap.add(foo.getName(), foo.getResource());
filesMultiMap.add(bar.getName(), bar.getResource());

MultiValueMap<String, Object> paramsMultiMap = new LinkedMultiValueMap<>();
paramsMultiMap.add("fooParam", "foo value");
paramsMultiMap.add("barParam", "bar value");

mockServiceServer.expect(ExpectedCount.once(), requestTo("/foobar"))
                .andExpect(method(POST))
                .andExpect(content().multipart().param("foo", "bar"))
                .andExpect(content().multipart().param("foo", "bar", "baz"))
                .andExpect(content().multipart().params(paramsMultiMap))

                .andExpect(content().multipart().file("fooFile",  foo.getBytes()))
                .andExpect(content().multipart().file("fooBarFile",  fooResource, barResource))
                .andExpect(content().multipart().file("bazFile",  customResourceMatcher))
                .andExpect(content().multipart().files("fooBarFile",  filesMultiMap))

                .andRespond(withSuccess().location(URI.create("/foobar/123")));

Related to https://github.com/spring-projects/spring-framework/pull/23671 which handles x-www-form-urlencoded requests

Comment From: rstoyanchev

I have processed these changes and scaled back the solution a bit. I've kept 2 multipart methods, one with MultiValueMap<String, ?> for exact matching and one with Map<String, ?> for a contains match. This meets the requirements of the original request #20653. It is how the RestTemplate takes input for multipart requests, and is consistent with the existing matcher for form data.

As for form data, i.e. the other PR # 23671, I've added a similar new method with a Map<String, String> for a contains match. It's next to the existing one in ContentRequestMatchers rather than at the top level MockRestRequestMatchers.

In any case thanks for the contributions.