Utils.resolveUri incorrectly resolves nested paths breaking JDK HttpClient transports

[chemicL]

The following reproducer:

    public static void main(String[] args) {
        System.out.println("URI: " + resolveUri(URI.create("https://example.com/some"), "/path").toString());
    }

prints

https://example.com/path

while it should be

https://example.com/some/path

This affects usages of HttpClientSseClientTransport and HttpClientStreamableHttpTransport with base

It's not used for WebClient-based transports which are free from this defect.

java-sdk version: 0.16.0

[chemicL]

I think this behaviour was introduced in #150 and noted in a follow-up comment: #150 (comment)

The tests added in the PR assume this behaviour is correct. I am not certain whether it's expected to behave this way. SO users also have issues with this behaviour.

If the baseUri from the reproducer has a trailing slash (https://example.com/some/) and the endpoint doesn't have the leading slash (path), the resolution looks correct.

This is a delicate subject so I won't be providing a fix at this time. Hoping for some pointers from someone more knowledgeable in URI specs.

[chemicL]

The behaviour with the URI class probably is correct according to the spec, but our expectations probably are wrong. Maybe we should change the paradigm a bit instead of assuming that the endpoint is appended to the base path or express some expectations (e.g. baseUri has to end with trailing slash and the mcp endpoint can't be absolute). I don't know. The goal probably was not to build something that external libraries can provide :)