Propagate Connection Closed Information up to top-level (fix #465)

[sebsto]

This PR implements a mechanism to propagate connection loss information from the Lambda runtime client to the runtime loop using EventLoopFuture, enabling termination without backtrace when the connection to the Lambda control plane (or a Mock Server) is lost.

This PR fixes #465

Changes Made
Core Changes:

• LambdaRuntimeClient: Added futureConnectionClosed property to signal connection loss via EventLoopFuture
• Lambda.swift: Modified runLoop to monitor connection status and throw an error on connection loss
• LambdaRuntime and ServiceLifecycle Integration: Modified to properly handle connection loss (and other top-level) errors and avoid application to crash with a backtrace.

Termination without a backtrace

• When connection to Lambda control plane is lost, the runtime exits cleanly
• Prevents hanging or zombie processes in testing/development environments
• Maintains compatibility with AWS Lambda service behavior (new runtime environment creation)

Use Cases

• Performance Testing: Prevents hanging when testing against MockServer
• Development: Cleaner shutdown behavior during local testing
• Production: Aligns with AWS Lambda service expectations for connection loss scenarios

[adam-fowler]

I think you'd be better to use the state machine to work out state, instead of adding additional variables, outside of the state machine.

Why don't you just check for the disconnected state in LambdaRuntimeClient.nextInvocation and if it is set throw a LambdaRuntimeError(code: .connectionToControlPlaneLost)

[sebsto]

Why don't you just check for the disconnected state in LambdaRuntimeClient.nextInvocation and if it is set throw a LambdaRuntimeError(code: .connectionToControlPlaneLost)

@adam-fowler This was already implemented (not by me). But nextInvocation() is not called while blocked on sendNextRequest() Basically, when the client is waiting for a call to GET /next to return, the code path does not go through nextInvocation()

[sebsto]

I think you'd be better to use the state machine to work out state, instead of adding additional variables, outside of the state machine.

That doesn't work in this context because I need to propagate the error from a callback inside LambdaRuntimeClient up to Lambda. The states are private to the LambdaRuntimeClient and the LambdaChannelHandler and can not be accessible from Lambda

Throwing errors is not an option neither because the only place where I can trap the connectionClosed event while the client is blocked on GET /next is inside a callback channel.closeFuture.whenComplete { result ... } This block can not throw.