Clean streamable 2

[jba]

mcp: various cleanups to streamable code

• Move the done field above mu: it does not need the mutex to be held.
• Use an atomic for signal, simplifying locking.
• Return from servePOST and serveGET instead of calling http.Error.

Each cleanup is in a separate commit.

[Copilot]

Pull Request Overview

This PR refactors the streamable transport code to improve its structure and simplify locking mechanisms. The changes consolidate stream-related data into a single struct and optimize concurrency handling.

• Introduces a new stream struct to encapsulate stream-related fields and logic
• Replaces the signals map with atomic operations to reduce mutex contention
• Refactors HTTP handlers to return status codes instead of calling http.Error directly

Comments suppressed due to low confidence (2)

mcp/streamable.go:274

• [nitpick] The function name signalChanPtr is ambiguous. Consider renaming to newSignalChannelPointer or createSignalChannel to better indicate it creates a new buffered channel pointer.

func signalChanPtr() *chan struct{} {

mcp/streamable.go:593

• [nitpick] The error message "session is closed" may not provide enough context for debugging. Consider including the session ID or operation context in the error message.

		return errors.New("session is closed") // TODO: should this be EOF?

[Copilot]

[nitpick] This TODO comment raises an important design question about termination behavior but lacks sufficient context. Consider expanding the comment to explain the current behavior difference between GET and POST methods.

Suggested change

	// TODO(jba,findleyr): why not terminate regardless of http method?
	// TODO(jba,findleyr): The current behavior terminates the connection only for POST requests
	// when all outstanding requests have been handled. This is based on the assumption that
	// POST requests are used for sending data to the server, and once the data is processed,
	// the connection can be safely closed. For GET requests, the connection remains open to
	// allow for potential future responses or streaming data. This distinction aligns with
	// the intended use cases of these HTTP methods as per the specification:
	// §6.4, https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#sending-messages-to-the-server.
	// Consider whether this distinction is necessary or if termination behavior should be
	// unified across all HTTP methods for simplicity and consistency.