Add ScalaNative version of `AwsLambdaRuntime`

[WojciechMazur]

This PR adds a Scala Native implementation of AwsLambdaRuntime. I've used a similar implementation in my local experiments outside tapir. There are still 3 problems with cross-compilation:

• org.typesafe.scalalogging is available only for JVM, it's usage on Scala.js and Scala Native would fail at link-time. PR contains a workaround allowing to use of a custom implementation in the form stdout logger. I'm not sure should it be included in the final version (Scala.js might not be tested currently because of the same reasons)
• Cats-Effect does not provide a runUnsafeSync() method for IO. We can workaround it by usage of Scala Promise and integration with SN internal queue execution context.
• We cannot use directly AWS SDK lambda.Context. That could be worked around by introducing another layer of abstraction allowing to either use AWS SDK LambdaHandler's or custom ones with Native/JS specific Context implementation. Alternatively, we could reimplement that part as a third-party library and publish only nir/sjir without bytecode (that's how Java stdlib is published to workaround double definitions on classpath)

The tests have been adjusted to run with native. I'm not sure it there is some built-in support for sharing sources between jvm-native without js, which might clean this up a bit.

[adamw]

I didn't yet read the whole PR, but maybe there is a JS/Native version of slf4j? then we could use that instead.

[kciesielski]

@WojciechMazur thanks a lot for this contribution!

org.typesafe.scalalogging is available only for JVM, it's usage on Scala.js and Scala Native would fail at link-time. PR contains a workaround allowing to use of a custom implementation in the form stdout logger. I'm not sure should it be included in the final version (Scala.js might not be tested currently because of the same reasons)

There's no JS/native version of slf4j. The only interesting approach I found was in log4s where they basically rewrote a part of the API, but I don't think we should go this way. I guess we'll leave your proposed logging implementation for now.

Cats-Effect does not provide a runUnsafeSync() method for IO. We can workaround it by usage of Scala Promise and integration with SN internal queue execution context.

The workaround looks interesting, are there any drawbacks we should be aware of?

We cannot use directly AWS SDK lambda.Context. That could be worked around by introducing another layer of abstraction allowing to either use AWS SDK LambdaHandler's or custom ones with Native/JS specific Context implementation. Alternatively, we could reimplement that part as a third-party library and publish only nir/sjir without bytecode (that's how Java stdlib is published to workaround double definitions on classpath)

Do I understand correctly, that we'd like to be able to expose the Context to tapir endpoints, so that devs can use it in their handling logic?

[kciesielski]

@WojciechMazur Could you take a look at my questions?