Expand gateway request logging in AWS, GCP, and airnode-client

[dcroote]

Closes #1351.

User story for the motivation and context of this PR:

As a [developer], I want to [access request processing logs on any of GCP, AWS, or the airnode-client without needing knowledge of Airnode request handling], so jthat [I can debug failing requests].

[amarthadan]

I'm a bit skeptical about how much will this help with the debugging process. I'm not saying it's bad, it will definitely help but I don't know if it's enough. But it's a start 🙂

[amarthadan]

Is this actually necessary? I think every request (lambda invocation) is logged in the AWS (and I think also in GCP) anyway. I don't think this adds anything. I would at least set it to debug.

[dcroote]

Edit: I've kept it for all, but changed it to debug. I think keeping it aids in visualizing the beginning of the block of logs pertaining to the request.

[amarthadan]

I would use the log options with the meta field everywhere where you want to add some data to the log message. Similar to how it's done in Airseeker. Or do you feel like it's better this way?

[dcroote]

I would use the log options with the meta field everywhere where you want to add some data to the log message. Similar to how it's done in Airseeker. Or do you feel like it's better this way?

Ah sorry it wasn't ready for re-review just yet 😅 I pushed that commit in order for CI to build the images that I could then test. But I think the meta option will be the better route 👍

[dcroote]

I'm a bit skeptical about how much will this help with the debugging process.

Agreed, but it's a start and provides a lot more than what the user / Airnode operator gets access to currently. I actually found it useful in debugging encoded parameters for a signed gateway request 😅

I would use the log options with the meta field everywhere where you want to add some data to the log message

For the local client, a requestId gets generated and added as logging metadata (with meta: as you suggested) to distinguish requests, but I found this is not needed for AWS & GCP as each generates their own form of unique ID for an incoming request that groups logs nicely (RequestId and executionId, respectively).