Handle txn registration if invocation registration is late

[lahsivjar]

What the PR does?

• Transaction registration can happen before the invocation is registered. Handle such cases by keeping the payload of transaction registration in a cache and handling it when the invocation is registered.
• Transaction registration will not have the duration of the transaction or if it does have it, the value will be a default value. We attempt to calculate the transaction duration based on the invocation timestamp, function deadline(for timeouts), OR runtimeDone log timestamp for agent issues.
• Increases the timeout for the deadline of extension from 100ms to 200ms.

Related to elastic/apm-agent-go#1323

[ghost]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-11-18T04:32:45.699+0000

• Duration: 8 min 51 sec

Test stats 🧪

Test	Results
Failed	0
Passed	202
Skipped	2
Total	204

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[axw]

Looks good, just one question.

[axw]

Should we require the agent to send the Lambda request ID along with the transaction ID and payload? Then it can always match up on request ID, and remove currentlyExecutingRequestID.

[lahsivjar]

That sounds plausible. I was motivated by keeping the lifecycle simple by exposing less arguments to the agent but I think sending requestID (maybe as a header?) will be better. Let me make the adjustments.

[lahsivjar]

I have updated the PR to accept request ID as a header x-elastic-aws-request-id. I didn't remove currentlyExecutingRequestID because I think adding the constraint for all agent data to have request ID as a header might not be a good idea but adding the requirement to the txn registration API should be okay. Additionally, the currentlyExecutingRequestID can be set reliably in both agent init or register invocation stages to ensure a correct value for later calls. Let me know your thoughts on it.

[axw]

Right, I forgot that we still need to associate events with the invocation. Looks good, thanks.