Add lambda runtime support

[muhamadazmy]

Add lambda runtime support

Summary:
This PR adds the support to run the user services on Amazon Lambda

[github-actions]

Test Results

  7 files  ±0    7 suites  ±0   3m 53s ⏱️ +27s
 52 tests ±0   51 ✅ ±0  1 💤 ±0  0 ❌ ±0 
213 runs  ±0  210 ✅ ±0  3 💤 ±0  0 ❌ ±0 

Results for commit 406c02b. ± Comparison against base commit 01168ff.

♻️ This comment has been updated with latest results.

[slinkydeveloper]

Few things come in my mind when reading it:

• https://docs.aws.amazon.com/lambda/latest/dg/rust-http-events.html -> this gateway proxy event seems exactly the event we should be handling (first example paragraph)
• https://docs.aws.amazon.com/lambda/latest/dg/rust-logging.html#rust-logging-tracing -> Probably we need to double check this, maybe we need to add tracing instrument macro to the service thing
• You very much reimplemented the impl Service<Request<Incoming>> for HyperEndpoint here in the lambda integration, i wonder if we could instead share some code just relying on http crate types. Pretty sure most of the code is already there, just needs to be reorganized...
• https://github.com/restatedev/sdk-rust/pull/70/files -> the endpoint api should not depend on the lambda thing imo. when you wrap Endpoint in LambdaEndpoint (and i think the user should do that explictly, same way they have to do that explicitly with HyperEndpoint) i guess you can force the discovery to be req/res...
• we need to improve a bit more the documentation on LambdaEndpoint type and describe how to deploy, link to the aws docs, etc. Plus probably we need an example template in the examples repo.
• LambdaEndpoint should be re-exported in the prelude when the feature is enabled

[muhamadazmy]

Thanks @slinkydeveloper for your PR, I will try to answer here:

• The ApiGatewayProxyRequest was the first thing I tried, unfortunately this fails to deserialize because the actual pay load I receive is missing some fields that are required in the ApiGatewayProxyRequest. This is why I had to create a smaller version of it. Later i found that this is exactly what is defined under here
• I will add instrumentation to the service.
• You very much reimplemented the impl Service<Request<Incoming>> for HyperEndpoint I am not sure what exactly you mean. This Service implementation is necessary for this to work with lambda_runtime crate. I already tried lambda_http also with no luck and you can see there is no much code. That being said, I already tried to use the HyperEndpoint with the lambda_http with no luck, was much cleaner and easier to implement this service glue code to map the lambda even to an sdk request.
• the endpoint api should not depend on the lambda thing imo. when you wrap Endpoint in LambdaEndpoint (and i think the user should do that explictly, same way they have to do that explicitly with HyperEndpoint) I absolute agree, and that was my initial idea to implement. However i had technical issues with implementing this. Once the Entrypoint is create via builder.build() there is no way to modify the protocol_mode, because the EntrypointInner is inside an Arc. So i had 2 options, either do Arc::into_inner() which might return None if the Arc has already been cloned, or Arc::unwrap_or_clone which doesn't work because EntrypoinInner is not cleanable. Instead I decided to add build_lambda() directly on the Builder to have a cleaner API.
• we need to improve a bit more the documentation I already updated the readme.md with some of the information. But wasn't sure how much details should I include.
• LambdaEndpoint should be re-exported in the prelude when the feature is enabled Sounds good to me, will do

[slinkydeveloper]

I already updated the readme.md with some of the information. But wasn't sure how much details should I include.

Perhaps a mention here:

sdk-rust/src/lib.rs

Line 31 in 24c829d

//! - [Serving][crate::http_server]: Start an HTTP server to expose services.

and generally more in-code docs on top of the LambdaEndpoint, check how we did it for HttpServer: https://docs.rs/restate-sdk/latest/restate_sdk/http_server/index.html I assume people land there more than on the readme (that's what we link from in docs.restate.dev too).

I absolute agree, and that was my initial idea to implement. However i had technical issues with implementing this. Once the Entrypoint is create via builder.build() there is no way to modify the protocol_mode, because the EntrypointInner is inside an Arc. So i had 2 options, either do Arc::into_inner() which might return None if the Arc has already been cloned, or Arc::unwrap_or_clone which doesn't work because EntrypoinInner is not cleanable. Instead I decided to add build_lambda() directly on the Builder to have a cleaner API.

mhhh now that I look at this, i wonder if Arc should be not at the Endpoint level, but in the HyperEndpoint instead and similarly in the LambdaEndpoint... Maybe that makes more sense, but anyway I think it's also ok to do Arc::into_inner() and panic, this code runs in the setup phase of the application anyway. I'm not fond of build_lambda() because it's not aligned with the rest of the API, where you need to wrap that yourself in the http server.