mcp: support stateless streamable sessions

[findleyr]

Support stateless streamable sessions by adding a GetSessionID function to StreamableHTTPOptions. If GetSessionID returns "", the session is stateless, and no validation is performed. This is implemented by providing the session a trivial initialization state.

To implement this, some parts of #232 (distributed sessions) are copied over, since they add an API for creating an already-initialized session.

In total, the following new API is added:

• StreamableHTTPOptions.GetSessionID
• ServerSessionOptions (a new parameter to Server.Connect)
• ServerSessionState
• ClientSessionOptions (a new parameter to Client.Connect, for symmetry)

For #10

[jba]

I'm confused about why the server is choosing statelessness. I thought there is some mechanism by which the client forces it, for example by sending a tool call without initialization.

[jba]

no longer just a placeholder

[jba]

Minor comment, ca be addressed in a followup.

[jba]

Describe default.

[BC-ACherednichenko]

@findleyr @jba sorry a bit late on this PR, i see that session ID is still getting verified in case header is provided, is it intentional?
My thinknig process is that in case we are in a stateless mode we can skip validation regardless of headers and etc, and treat every request as a new one, fetching the header seems to be limiting this capability

	var session *StreamableServerTransport
	if id := req.Header.Get(sessionIDHeader); id != "" {
		h.sessionsMu.Lock()
		session, _ = h.sessions[id]
		h.sessionsMu.Unlock()
		if session == nil {
			http.Error(w, "session not found", http.StatusNotFound)
			return
		}
	}

Wanted to check with you here before jumping into the issue

[findleyr]

@BC-ACherednichenko but why would the client provide a session ID if the server didn't return one? I guess I'm not understanding the use-case.

[BC-ACherednichenko]

@findleyr it is still related to the #148, since we put on ice the distributed sessions interface we have been wondering if it is possible to solve this problem via stateless mode

In particular, if stateless mode could be completely without session validation or etc (sort of you pass the flag, and sdk acts as if sessions did not exist at all), the mcp-session-id emission, management and distributed storage could have been moved to tools middleware layer (upper layer of the server).

Currently it reacts right away on the service header mcp-session-id, which i feel can be more flexible and could be managed at the concrete server implementation discretion