Improve nullability in DefaultResponseCreator

[bjmi]

In response to the call for improvements to Spring code regarding Jspecify Nulls are dead - Moritz Halbritter | IntelliJ IDEA Tech Talks here is an enhancement for DefaultResponseCreator encountered during writing tests.

The DefaultResponseCreator builder from spring-test unnecessarily restricts certain method parameters to non-nullable types although the nullable types are supported.
This just makes writing parameterized tests, for example, unnecessarily difficult.

[rstoyanchev]

HttpHeaders does allow null values as a way to remove. On the other hand DefaultResponseCreator is used to build a response and is therefore additive, and flagging null is potentially useful. Could you provide a sketch of a sample test class that shows a common scenario?

Broadly, we have many similar facade APIs over HttpHeaders -- Rest|WebTestClient, Rest|WebClient, functional server APIs, and others that should be considered too.

[bjmi]

E.g. following parametrized test exercising the fetchStatus() depending on a nullable content-type.

Webservice webservice;  // using RestClient inside

@CsvSource({
	"https://example.org/status.txt , text/plain      ",
	"https://example.org/status.txt ,                 ",
	"https://example.org/status.json, application/json", 
	"https://example.org/status.json,                 ",
})
@ParameterizedTest(name = "{arguments}")
void fetchStatus(URI url, @Nullable MediaType mediaType) {
	mockServer.expect(requestTo(url))
			.andRespond(withSuccess().contentType(mediaType));

	SomeStatus result = webservice.fetchStatus(url);

	assertThat(result).isEqualTo(SomeStatus.OK);
	mockServer.verify();
}

Personally, I find builders useful that allow to unset properties again when they aren't needed.
It allows to create a DefaultResponseCreator with resonable defaults for tests that can be changed easily if the defaults doesn't fit.