feat: Added AutoCloseable interface

[YunKuiLu]

I've added the AutoCloseable interface to the following classes to support the try-with-resources statement:

• LifecycleInitializer
• McpAsyncClient
• McpAsyncServer
• McpServerTransportProvider
• McpSession
• McpSyncServer
• McpTransport
• McpTransportSession

Motivation and Context

In order to support the try-with-resources block for these classes.

How Has This Been Tested?

N/A

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

[134130]

IMHO, current close() means immediately shutdown, and closeGracefully() is the graceful shutdown.

AutoClosable should be graceful shutdown as default, as ExecutorService does. see: https://stackoverflow.com/questions/41393417/why-does-the-executorservice-interface-not-implement-autocloseable

[YunKuiLu]

IMHO, current close() means immediately shutdown, and closeGracefully() is the graceful shutdown.

AutoClosable should be graceful shutdown as default, as ExecutorService does. see: https://stackoverflow.com/questions/41393417/why-does-the-executorservice-interface-not-implement-autocloseable

Learned something new again! I’m thinking — would it make sense to introduce a closeNow() method to replace the current close(), and update the existing close() to call this.closeGracefully().subscribe()? ( like ExecutorService.shutdownNow() )

[134130]

IMHO, current close() means immediately shutdown, and closeGracefully() is the graceful shutdown.

AutoClosable should be graceful shutdown as default, as ExecutorService does. see: https://stackoverflow.com/questions/41393417/why-does-the-executorservice-interface-not-implement-autocloseable

Learned something new again! I’m thinking — would it make sense to introduce a closeNow() method to replace the current close(), and update the existing close() to call this.closeGracefully().subscribe()? ( like ExecutorService.shutdownNow() )

It would be great if the sdk supports close() with a graceful shutdown from the beginning, but currently not. If we change the close's behavior, it will be a breaking change in almost every library user.

I think many users are familiar with using network libraries, which may require close resources, so the AutoClosable interface is not necessary.

[134130]

@YunKuiLu

I'm not good at English. The "so the AutoClosable interface is not necessary" is just my opinion.

I'm sorry if you felt bad.

[YunKuiLu]

@134130
No worries at all! I just felt a bit inconvenient not being able to use try-with-resources when writing tests, so I created this PR. But I didn’t think it through. Your feedback is totally valid and helpful!