feat(rust): add second example using non-op internal extension, expand README

[jlizen]

Issue #, if available:
Closes: #1

Description of changes:
The current Rust example uses an external extension, CloudWatch Lambda Insights. It works fine, but it adds overhead if you don't need the extension since it requires a standalone process running. It also adds billing costs / cold start / etc.

Adding an additional example that uses an internal extension instead. I updated the README to discuss the difference between both.

Related PR on the aws-lambda-rust-runtime side:

• feat(tracing, lambda-runtime): add support for custom writer with default tracing subscriber, add turnkey graceful shutdown helper behind 'graceful-shutdown' feature flag awslabs/aws-lambda-rust-runtime#982

Testing
Each example has its own SAM template. I tested each end to end including deploy, sending traffic, validating the graceful shutdown in logs, etc. The two examples can co-exist in the same account without issue.

Note that graceful shutdown is not currently testable locally via cargo lambda watch, ref:
cargo-lambda/cargo-lambda#850

Internal extension logs:

INIT_START Runtime Version: provided:al2023.v90	Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:afd9ea1d72c8135b0bcfe7ebce16e06002647cb9e5195edeb536e21e1ef6d259
EXTENSION	Name: no-op	State: Ready	Events: [INVOKE]
START RequestId: 69e2cff4-7740-4d6e-bc2f-4f317214fba8 Version: $LATEST
END RequestId: 69e2cff4-7740-4d6e-bc2f-4f317214fba8
REPORT RequestId: 69e2cff4-7740-4d6e-bc2f-4f317214fba8	Duration: 37.74 ms	Billed Duration: 62 ms	Memory Size: 128 MB	Max Memory Used: 16 MB	Init Duration: 23.90 ms	
[runtime] SIGTERM received
[runtime] Graceful shutdown in progress ...
[runtime] Graceful shutdown completed

External extension logs:

INIT_START Runtime Version: provided:al2023.v90	Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:afd9ea1d72c8135b0bcfe7ebce16e06002647cb9e5195edeb536e21e1ef6d259
LOGS	Name: cloudwatch_lambda_agent	State: Subscribed	Types: [Platform]
EXTENSION	Name: cloudwatch_lambda_agent	State: Ready	Events: [SHUTDOWN, INVOKE]
START RequestId: b90265f5-f87e-4642-a1a2-2f77f4ca224e Version: $LATEST
END RequestId: b90265f5-f87e-4642-a1a2-2f77f4ca224e
REPORT RequestId: b90265f5-f87e-4642-a1a2-2f77f4ca224e	Duration: 65.05 ms	Billed Duration: 153 ms	Memory Size: 128 MB	Max Memory Used: 26 MB	Init Duration: 87.50 ms	
[runtime] SIGTERM received
[runtime] Graceful shutdown in progress ...
[runtime] Graceful shutdown completed

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jlizen]

A couple updates:

I do have a PR out to tokio for biased support in try_join:
tokio-rs/tokio#7307

If we merge this with the TODO still in place, I can circle back and cut it over once it lands.

I also have cargo lambda watch working locally against the example with this fix in place:
cargo-lambda/cargo-lambda#853

[jlizen]

Capturing some offline discussion with bnusunny@:

@jlizen we can make it even simpler: add a shutdown hook in rust runtime, so it will be dead simple to handle graceful shutdown. Under the hood, the rust runtime can register a dummy internal extension.

Yeah I was thinking the same. I'll poke around with that tomorrow.
I was previously concerned about overhead, since if you are forced to subscribe to invokes, that means that the extension future will be woken for each event. Which means that you probably want to call it within try_join!, which starts to be pretty messy to abstract away from the user from an api perspective.
But as you correctly pointed out, there is no need to subscribe to events. So, it should be fine to just spawn a task to drive the no-op extension in the background.

I'm fine to put this PR on hold in anticipation of such a feature, if preferred. Or, I can backport usage of that new API once it is available. Up to you.

[jlizen]

Graceful shutdown hook PR: awslabs/aws-lambda-rust-runtime#982