CAMEL-24577: platform-http path variables follow the path Spring matched

[Croway]

CAMEL-24577

What

SpringBootPlatformHttpBinding.populateRequestParameters() evaluated the rest placeholders of the consumer
path against getRawPath(request), which is request.getRequestURI() with the servlet context-path removed:
still percent-encoded and still carrying matrix parameters.

Spring dispatched the request against the parsed RequestPath, whose segments are decoded and stripped of
matrix parameters, so the header could disagree with the path the request was matched on. For a consumer
platform-http:/greeting/{name}:

Request	header name before	header name now
/greeting/%61dmin	%61dmin	admin
/greeting/John%20Doe	John%20Doe	John Doe
/greeting/name;v=1	name;v=1	name

This also brings the starter in line with the vertx engine, which sets the decoded RoutingContext.pathParams()
values.

How

Only the placeholder evaluation changed. It now uses ServletRequestPathUtils.parse(request) and joins the
segments of pathWithinApplication() by their valueToMatch() - the very values Spring matched the pattern
against - falling back to the raw path if the request cannot be parsed.

The path is parsed rather than read back from the RequestPath Spring cached in the request attribute: the
consumer services the request on its own executor, and the dispatch that cached it may have removed the
attribute by then, which would make the header value depend on timing.

getRawPath() is untouched, so Exchange.HTTP_PATH (CamelHttpPath) still reports the raw path with the
context-path removed, and the overrides added by CAMEL-22116 and CAMEL-23191 keep working.

populateRequestParameters now checks the consumer path for placeholders before computing the path, so a
consumer without placeholders does no extra work.

Behaviour change

Path variable headers for percent-encoded segments or segments with matrix parameters change as shown above.
An application that decoded the header itself, or parsed matrix parameters out of it, must drop that handling.
Requests whose path variables contain neither are unaffected. An upgrade guide entry will be proposed
separately in apache/camel.

Tests

• New SpringBootPlatformHttpPathVariableTest: plain, percent-encoded, encoded space, matrix parameter, and
  REST DSL path variables, each also asserting CamelHttpPath is unchanged. Four of the five fail without
  the fix.
• New SpringBootPlatformHttpBindingPathVariableTest: services the consumer directly, with no dispatch having
  cached a request path, pinning that resolution does not depend on that attribute.
• Full camel-platform-http-starter suite green (53 test classes).

Documentation: a "Path variables" section was added to the starter docs.

Claude Code (Opus 5) on behalf of Federico Mariani

[Croway]

The CI failure here is SpringBootPlatformHttpCookiesTest.echoCookie, which fails on main against the current camel-platform-http snapshot since CAMEL-24453 made the request-header echo suppression case-insensitive. The test fix is in #1938; once that is merged the checks here can be re-run without a rebase.

Claude Code on behalf of Federico Mariani