Fixing normalErrorPageWorks() test

[rjuare8]

Fix HttpStatusTests.normalErrorPageWorks for error responses without message field

While running the Spring Cloud Gateway WebFlux tests on this commit, I ran into a failure in HttpStatusTests.normalErrorPageWorks():

[ERROR] Failures:
[ERROR]   HttpStatusTests.normalErrorPageWorks:89->lambda$normalErrorPageWorks$0:90 
Expecting actual:
  {"error"="Internal Server Error", "path"="/httpbin/exception", "requestId"="e5989a61-8", "status"=500, "timestamp"="2025-12-02T05:16:42.307Z"}
to contain key:
  "message"

In this environment, the default error response includes a requestId field, but does not include a message field. The existing assertion expected "message" to always be present in the error body, which caused normalErrorPageWorks to fail even though the response was otherwise correct (status 500, path, timestamp, etc.).

This PR relaxes the assertion to:

• Continue to assert the core error fields (timestamp, path, status, error), and
• Allow the error payload to contain either a message key or a requestId key (or both).
• This keeps the intent of the test (“normal error page returns a structured JSON error body with the expected metadata”) without hard-coding a particular error attribute configuration.

Summary of changes

spring-cloud-gateway-server-webflux/src/test/java/org/springframework/cloud/gateway/test/HttpStatusTests.java:

Before:

.expectBody(Map.class)
	.consumeWith(result -> assertThat(result.getResponseBody())
		.hasSizeGreaterThanOrEqualTo(5)
		.containsKeys("timestamp", "path", "status", "error", "message"));

After:

.expectBody(Map.class)
	.consumeWith(result -> {
		Map<String, Object> body = result.getResponseBody();

		assertThat(body)
			.hasSizeGreaterThanOrEqualTo(5)
			.containsKeys("timestamp", "path", "status", "error");

		assertThat(body.keySet()).containsAnyOf("message", "requestId");
	});

Motivation

With the newer Spring Boot error handling defaults, the error JSON for /exception can legitimately omit "message" while still including other helpful metadata such as "requestId". The previous assertion hard-coded the presence of "message", causing failures like the one above despite the behavior being otherwise correct.

By asserting the stable core fields and then allowing either "message" or "requestId" in the key set, the test:

• Still validates that a structured error body is returned for /exception.
• Remains compatible with configurations where message is not exposed.
• Avoids spurious failures like the one shown above, while preserving coverage of the intended behavior.

[ryanjbaxter]

I think this is fine for this test. We could also set

spring:
  web:
    error:
      include-message: always