Remove tokio rt-multi-thread feature from lambda_runtime and lambda_extension, and possibly rt as well

[jlizen]

Currently the lambda_runtime crate has an unconditional dependency on tokio withe rt-multi-thread feature enabled:

• https://github.com/awslabs/aws-lambda-rust-runtime/blob/main/lambda-runtime/Cargo.toml#L53
• https://github.com/awslabs/aws-lambda-rust-runtime/blob/main/lambda-extension/Cargo.toml#L35

I'm struggling to see anywhere this dependency is actually used. Meanwhile, given that lambdas only receive one request at a time, it will frequently make sense for callers to only want to use the current thread runtime anyway (ref: #985 ).

I don't think we even need the rt (not multithreaded) feature for lambda-runtime, not seeing anywhere we are spawning or interacting with feature gated APIs. Though, for #983 we would need it, so probably ok to leave in?

Anyway, is there a reason we need to depend on the multithreaded runtime feature? Am I missing something?

[jlizen]

On thinking more about it, I don't think I actually need a task::spawn for #983 , I would rather just return a future and let the caller decide.

That leaves no usages of tokio::rt/task whatsoever in aws-lambda-rust-runtime, we could completely ditch the feature. And then for lambda_extension, we are implicitly spawning some background loops for our telemetry and log processor, which is a bit awkward. We could return a future but definitely would be semver breakage.

Anyway probably ripping out any of these features in semver breakage, since if somebody was implicitly getting them enabled by aws-lambda-rust-runtime, their code could break.

So presumably this would all require a new minor version (since we are pre-1.0)

[jlizen]

Ok, I do need tokio::rt for graceful shutdown handling, at least the easy way. The listener panics if used outside of rt - ref. But anyway I can just put the whole thing behind a feature flag.

So I think that the larger point remains wrt to removing rt dependency from base crate.

It might actually simplify the migration path to have the feature flag for tokio/tokio-rt/graceful-shutdown/etc. Since we could make it a default feature. Makes people less likely to break if they don't change their tokio dependency.

[bnusunny]

Even through one Lambda sandbox only receives one request at time, nothing prevents people starting multiple async tasks to handle that request. I think you also reached the same conculsion at #985.

[jlizen]

Even through one Lambda sandbox only receives one request at time, nothing prevents people starting multiple async tasks to handle that request. I think you also reached the same conclusion

That may be, but it still seems awfully infectious to enable rt-multi-thread when we aren't actually using it for anything? It is the caller that needs to instantiate the runtime anyway. Most of the time, they should be using rt-multi-thread, yes, but they could also be using non-tokio runtimes or a more esoteric current-thread runtime where they are careful about managing concurrency.

For the purposes of feature hygiene, shouldn't we avoid enabling that flag that we aren't directly using?