Provide ability to incorporate the entire input as a Message's payload (no parsing) for AWS

[M0rious]

Describe the bug
We are using SpringCloudFunctions on AWS for Lambdas.
The messages send to the Lambdas contain a property "payload".
This worked fine up until spring-cloud-function-adapter-aws@4.0.6.
With the current version 4.1.2 the message does not reach the lambda implementation correctly.
Only the "payload" property gets passed to the function-code

Sample
Deploy a SCF-Lambda to AWS or Localstack and log the input:

@SpringBootApplication
@Slf4j
public class SampleLambda {

  @Bean
  public Function<Message<String>, String> transformMessage() {
    return input -> {
        log.info("Debug: {}", input.getPayload());
      return input.getPayload();
    };
  }
}

Sample-Input:

{
  "a": "b",
  "payload": {
    "c": "d"
  }
} 

Output:

"Debug: {\"c\":\"d\"},.."

[olegz]

Since this message does not correspond to any valid format we really don't know what "a": "b", is. Wouldn't it be better if you incorporate it under headers

"headers": {"a":"b"}

We monitor that?

[M0rious]

The lambda is triggered by a step function that builds a json object as input for the lambda.
Why would we pass this as a header to the lambda?
Here an extended example:

{
  "someProperty": "someValue",
  "payload": {
    "otherProperty": "otherValue"
  }
} 

Would log:
"Debug: {\"otherProperty\":\"otherValue\"},.."
Everything outside of the "payload" property of the message we build for the lambda does not reach our code.

[mrjv]

We are getting a similar error after upgrading to Spring Cloud Function 4.1.1. (Or actually same as #1135, but after upgrading to 4.1.2 I expect the same as above). Same scenario as @M0rious: our Lambda input request has a json field called "payload" that is not expecting any special handling on an AWS Lambda adapter level.

The special handling of the "payload" field seems to have been introduced by the following commit, although I'm not sure how the change is related to #1086 as mentioned in the commit message:
8a93e10#diff-c3541839d4b70d7bf7b3c116f62949cdab0fd8923e1ccf57a6788e6411d67d87

@olegz What was the original reason for adding special handling of requests having a "payload" field? Ideally there would be some way to opt in or opt out from this behavior to avoid breaking changes to existing AWS Lambda functions.

[olegz]

Don't get me wrong, we can fix it, just trying to understand your expectation and what I read is that given that Spring Message has a distinct payload field, you would expect/like your payload to go there and the rest as headers, correct?

[M0rious]

Don't get me wrong, we can fix it, just trying to understand your expectation and what I read is that given that Spring Message has a distinct payload field, you would expect/like your payload to go there and the rest as headers, correct?

Yes - if we send a JSON-Message to the Lambda we expect the whole message to be in the payload field - regardless of the fields contained in the message we send.

We use Message as Input for the Lambda so we can call getHeaders to use e.g. the 'aws-context' header for logging.

[olegz]

We probably would need some boolean flag as a property to differentiate between when we parse the JSON into a Message vs when we simply include the entire JSON as a payload