allow custom initialization of the HandlerType of the LambdaRuntime

[tomerd]

Motivation: Provide the flexibility for custom initialization of the HandlerType as this will often be required by higher level frameworks.

Modifications:

• Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
• Update downstream code to use HandlerProvider
• Update upstream code to support passing Hanlder Type of Handler Provider
• Add and update tests

Originally suggested and coded by @tachyonics in https://github.com/swift-server/swift-aws-lambda-runtime/pull/308

[tomerd]

@tachyonics wdyt?

[tachyonics]

@tachyonics wdyt?

This will work for our use case although not quite as convenient as what I had. My only concern is that handlerProvider returns a ByteBufferLambdaHandler which has a makeHandler function requirement that will not actually get used. In our code we can just not implement that method but conceptually it seems a bit odd at the runtime level.

[tomerd]

@tachyonics wdyt about https://github.com/swift-server/swift-aws-lambda-runtime/pull/310/commits/792d1c1adb0f49704a28f9093e87b618d48b5f5b? I dont love the name CoreByteBufferLambdaHandler but hopefully this address the need better?

[tomerd]

thanks @tachyonics, so now to the hard part - choosing a name.

cc @fabianfett @sebsto @yim-lee @ktoso

any good ideas?

[tachyonics]

so now to the hard part - choosing a name

@tomerd NonInitializingByteBufferLambdaHandler?

[tomerd]

@tachyonics updated to NonInitializingByteBufferLambdaHandler. wdyt?

[tachyonics]

Just some small comments about comments. Otherwise lgtm.

[tomerd]

@tachyonics new name idea: LambdaRuntimeHandler. wdyt?

[tachyonics]

I'm good with this!

[tomerd]

@fabianfett any concerns?

[fabianfett]

Tbh. I think this doesn't solve the actual issue. The lifetime handling in Lambda was designed and implemented before ServiceLifecycle came about. For this reason, using long running clients in Lambda currently feels absolutely weird.

For this reason, I think, we should reconsider what the Lambda API should look like taking into account that it should play nicely with ServiceLifecycle.

General ideas:

1. LambdaRuntime should implement Service
2. If a Lambda runs locally it should set up a ServiceGroup to handle signal handling
3. If a user needs long running Services within their Lambda they should be able to use ServiceGroups to manage their lifetimes.