fix(aws-lambda): remove AWS Lambda API latency from kong latency

[windmgc]

Summary

This commit removes the latency attributed to AWS Lambda API requests from Kong's measured latencies (latencies.kong, KONG_RESPONSE_LATENCY, X-Kong-Response-Latency), ensuring that these delays are not mistakenly considered as originating from Kong.

This is an alternative of #12678, but this PR fix the latency problem only within the AWS-Lambda plugin scope without introducing anything new, so that we can have a simple and appropriate fix for the user.

Checklist

• The Pull Request has tests
• A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

FTI-5261

[liverpool8056]

One more question:
Why is ctx.KONG_PROXIED not set in this plugin?
Two side effects for this (I'm not sure if they matter):

• KONG_latencies.kong always respect KONG_RESPONSE_LATENCY instead of KONG_PROXY_LATENCY
• The requests hitting the plugin are considered un-proxied.

[windmgc]

@liverpool8056

Why is ctx.KONG_PROXIED not set in this plugin?

The KONG_PROXIED represents that the request will go to the upstream. In a serverless plugin like aws-lambda, plugin will call PDK's response function and use a delayed_response conditional block to do special treatment - because the requests will not go to the upstreams. And the access phase will end as soon as the ngx.exit() is being called inside the PDK function, so ctx.KONG_PROXIED will not be set

KONG_latencies.kong always respect KONG_RESPONSE_LATENCY instead of KONG_PROXY_LATENCY
The requests hitting the plugin are considered un-proxied.

Yes, this is what serverless plugin expects.

[bungle]

Just a note here. We have huge number of plugins that do round trips and network io in synchronous fashion. AWS lambda is just one. We have Azure Functions, we have OIDC, we have OPA, OAuth Introspection, Session. A lot of our plugins communicate to Redis, which are beyond Kong, but somewhat on our land as well. Whenever there is network io, it is really hard to determine who's fault the added latencies are. It is hard to tell where our code stops and where other reasons start to affect. If we were to measure our non-yielding code only, then it is usually just around 0-1ms (the code execution time). But if we need to do network io on request time it gets wildly compilicated to count any numbers.

[windmgc]

@bungle Yes, that is also what I'm thinking about. This PR's scope is to only solve the aws-lambda plugin without introducing anything new to have a quick fix for FTI-5261.

[bungle]

@windmgc, Not a big deal, just thinking if it would be better to use kong.ctx.plugin here (feel free to disagree and mark this resolved).

comments were addressed

[team-gateway-bot]

Successfully created cherry-pick PR for master:

• https://github.com/kong/kong-ee/pull/8932