mcp: Implement KeepAlive for client and server

[rwjblue-glean]

Motivation and Context

Implement KeepAlive features from the design doc

Closes #24

How Has This Been Tested?

Tested locally (unit tests).

Breaking Changes

N/A

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

I can send a follow-up PR adding an example with a StreamableHTTP server that uses the keepalive if that would be helpful.

[jba]

It looks like a user Close and the Close from the startKeepalive goroutine could race.
I don't think they can, but it's worth an explanation, in terms of happens-before relations, why no mutex is needed for keepaliveCancel. (If you don't understand what I'm talking about, I can explain further.)

[rwjblue-glean]

Ya, I agree, I'm pretty sure that we do not need a mutex here, I've added the following comment explaining the flow and why it's safe:

	// Note: keepaliveCancel access is safe without a mutex because:
	// 1. keepaliveCancel is only written once during startKeepalive (happens-before user Close calls)
	// 2. context.CancelFunc is safe to call multiple times and from multiple goroutines
	// 3. The keepalive goroutine calls Close on ping failure, but this is safe since
	//    Close is idempotent and conn.Close() handles concurrent calls correctly

Please double check my reasoning though!

[jba]

Add a comment saying that we must assign this before starting the goroutine, so we cannot return it.

(I first thought "why not just return the cancel func instead of passing in a pointer?" But it would be racy.)

[rwjblue-glean]

Good suggestion, thank you! Updated with this comment:

	// Assign cancel function before starting goroutine to avoid race condition.
	// We cannot return it because the caller may need to cancel during the
	// window between goroutine scheduling and function return.

[samthanawalla]

LGTM