Wrap incoming extension events in a struct

[calavera]

Signed-off-by: David Calavera david.calavera@gmail.com

Issue #, if available:

Fixes #392

Description of changes:

This new structure can be used to pass additional information to the extension in each invocation, like the extension id that the Runtime assigns to the extension when it's initialized.

I'm not super keen in cloning the id in every event, but if I start messing with lifetimes, the extension trait becomes much more complicated to implement. I think this is good enough to fix the current issue, and we can iterate on it if it really becomes a problem before making the crate more stable.

By submitting this pull request

• I confirm that my contribution is made under the terms of the Apache 2.0 license.
• I confirm that I've made a best effort attempt to update all relevant documentation.

[bahildebrand]

LGTM!

[tannerntannern]

@calavera Correct me if I'm wrong, but I'm not sure this actually resolves the linked issue. According to the Lambda Logs API docs (emphasis mine):

To subscribe to receive logs, you need the extension identifier (Lambda-Extension-Identifier). First register the extension to receive the extension identifier. Then subscribe to the Logs API during initialization. After the initialization phase completes, Lambda does not process subscription requests.

As I understand it, accessing the extension id during an invoke event and subscribing to the Logs API at that point would be too late (not sure if that was the intended path). Subscribing to the Logs API must happen between extension registration and the first call to /event/next, which still doesn't appear to be possible.

To clarify, I don't think this is a bad change. The Lambda Logs API also sends back the extension id in the response headers for the /event/next endpoint, so if anything these changes bring us more in line with the actual AWS APIs. I don't think we can say #392 is resolved however.