Stop the host when the single session server service finishes

[stephentoub]

@halter73, is this the right way to do it?

Contributes to #221
Closes #155

[halter73]

The host should do this for you.

https://github.com/dotnet/runtime/blob/367e0a8a23e444a94c029fcb72dcb4ac66bd6717/src/libraries/Microsoft.Extensions.Hosting/src/Internal/Host.cs#L236

However, #221 and #155 were fixed by #225. I hadn't really noticed the long shutdown times (edit: with SSE which is not relevant to this PR) before because I typically closed the response stream on the client side before shutting down the server. The ConnectCallback Stream.DisposeAsync bug uncovered the long shutdown issue for me. I left a small note in my PR descriptions about fixing this.

• Use ApplicationStopping token for SSE responses. SignalR does the same thing FWIW

And then this in the comment:

// If the server is shutting down, we need to cancel all SSE connections immediately without waiting for HostOptions.ShutdownTimeout
// which defaults to 30 seconds.
using var sseCts = CancellationTokenSource.CreateLinkedTokenSource(context.RequestAborted, hostApplicationLifetime.ApplicationStopping);

https://github.com/modelcontextprotocol/csharp-sdk/pull/225/files#diff-f740d1d73af0aac882eeee83a3293823ebb6fba888daddd601a7da3af6c0a853R66

I can close the two issues as fixed by my PR if you want. Saving 30 seconds during shutdown is dramatic.

[halter73]

Sorry, I just noticed both those issues were stdio servers. I'm not sure what's going on there. I do think changes similar to dotnet/cli#10720 might help.

[stephentoub]

The host should do this for you.

When StopAsync is called. StopAsync isn't being called.

I'm not sure what's going on there.

As far as I can tell, the hosting infrastructure doesn't automatically exit when a background service exits.

I do think changes similar to dotnet/cli#10720 might help.

It would mask it, certainly. But I think the server should be able to gracefully exit on its own.
#155 (comment)

[halter73]

It took me a second, but now I see the logic behind this change. As you could probably tell, when I left my first comment, I was still thinking about HTTP scenarios. I'm not used to single-session servers 😆

[halter73]

It'd be nice if we could have a test though. It should be easy enough to have a client close the stream and verify the server host stops within a timeout.