Currently `HttpServer` allows matching a request path `/foobar` to context path `/foo`. This surprising behaviour was first reported in JDK-8225479, and there, the issue is worked around by documenting it. This issue aims to improve the behavior of `HttpServer` to avoid this pitfall.

## Motivation

This issue has two consequences:

1. It has been causing confusion while implementing tests – see this[1] most recent example. Due to this bug(?), tests need to create handlers for `/foo/` and target requests to `/foo/bar` to ensure that the right handler is invoked. This not only confuses the developer implementing the test, but also the person reading the code.

[1] https://github.com/openjdk/jdk/pull/25844#discussion_r2152391670

2. The behavior is unexpected. Neither popular JEE/Jakarta frameworks (e.g., Tomcat), nor others (e.g., Spring Boot) map handlers this way.

## Proposal 1: Implicitly add a trailing slash

The proposal is to silently add a '/' to any context path that doesn't already have one at each time of use. It probably makes sense to record the context exactly as the caller specified it (with or without the '/') and return the same path from HttpContext.getPath. Otherwise, that could result in surprising behavior after the change (getPath() returning a different path to the one specified).

The reason for silently adding the '/' is to support the most likely misuse of the current behavior ie registering /foo while intending the behavior of /foo/

## Proposal 2: Change the prefix path matching logic

We can change the path handling such that the context path `/foo` matches request paths `/foo`, `/foo/`, `/foo/bar`, but not `/foobar`? This will resolve the issue without implicitly augmenting the path, which causes "What to return from `HttpContext::getPath`?" problems.

## Backward compatibility

The proposed safer and less surprising behaviour introduces a backward incompatibility: Request path `/foobar` will *not* match to context path `/foo` anymore.