Improved error messages about payload deserialization

[rimutaka]

This PR makes errors about payload deserialization into a concrete event type more informative.

For example, my lambda had LambdaEvent<ApiGatewayProxyRequest> and was failing with the following error message:

ERROR lambda_runtime::layers::api_response: building error response for Lambda Runtime API error=DeserializeError { inner: Error { path: Path { segments: [] }, original: Error("missing field `httpMethod`", line: 1, column: 49) } }

That error message makes perfect sense to the developer of the runtime. A runtime user is likely to be stumped.

The problem is a mismatch between the payload and the target type, but the error says building error response for Lambda Runtime API. What does that mean?

I had to look up the runtime source to understand what's going on.

The proposed message is makes it clearer that the error happened before the handler was called, relates to the deserialization and suggests where to find more info (TRACE):

ERROR lambda_runtime::layers::api_response: Request payload deserialization into LambdaEvent<T> failed. The handler will not be called. Log at TRACE level to see the payload. error=DeserializeError { inner: Error { path: Path { segments: [] }, original: Error("missing field `httpMethod`", line: 1, column: 49) } }

I also added a note about logging with TRACE to see the raw payload. It is a very useful feature that is worth mentioning. I accidentally stumbled across it while working on this PR.

Looks like the runtime uses TRACE and not DEBUG.

Changes made

• made error messages more informative
• added a suggestion to log at TRACE level to README

🔏 By submitting this pull request

• [x] I confirm that I've ran cargo +nightly fmt.
• [x] I confirm that I've ran cargo clippy --fix.
• [x] I confirm that I've made a best effort attempt to update all relevant documentation.
• [x] I confirm that my contribution is made under the terms of the Apache 2.0 license.