Add Codable helpers for FunctionURL, APIGatewayV2, and SQS

[natanrolnik]

Add helpers for FunctionURL, APIGatewayV2, and SQS events to ease usage of Decodable and Encodable types

Motivation:

When using Function URL (or API Gateway) events and outputs, and SQS events, it is very common to decode a Decodable body, or encode a Codable type into a function URL response. This PR adds convenient methods that are easy to use, but also maintain a level of customization by allowing custom JSON encoders/decoders.

Modifications:

• Add helper method to encode Encodable types into a FunctionURLReponse or APIGatewayV2Response
• Add helper method do decode Decodable types from a FunctionURLRequest or APIGatewayV2Request
• Add helper method to decode multiple Decodables from SQSEvent records, or from a single SQSEvent.Message
• Add test cases (generated with the help of LLM. Thanks Anthropic. Verified tests pass after many tries, and went over the final changes to make sure they're correct)

Result:

The changes allow the following usage:

let decodedBody = try functionURLRequest.decode(MyPayload.self)

Instead of:

var bodyData = functionURLRequest.body?.data(using: .utf8) ?? Data()

// check for base 64 encoding of the body, and if that's the case, decode that into bodyData
if isBase64Encoded, let base64Decoded = ... {
   bodyData = base64Decoded
}

let decodedBody = JSONDecoder().decode(MyPayload.self, from: bodyData)

The same is similar when decoding SQS event messages.

And when encoding a response:

func handle(...) -> FunctionURLResponse {
    // business logic
    let responsePayload = MyResponse(text: "Hello Lambda", count: 613)
    return .encoding(responsePayload)
}

Instead of:

func handle(...) -> FunctionURLResponse {
    // business logic
    let responsePayload = MyResponse(text: "Hello Lambda", count: 613)
    do {
        let data = try JSONEncoder().encode(responsePayload)
        return .init(
            status: .ok,
            body: String(data: data, encoding: .utf8)
        }
    } catch {
        return .init(
            status: .internalServerError,
            body: "Internal server error: \(error)"
        }
    }
}

[sebsto]

Thank you @natanrolnik for this welcome change.
Can you add the license header to all Swift files (except Package.swift) and be sure to run the ./scripts/format.sh on your staged files to apply formatting rules.

[sebsto]

Thank you so much for this addition. I left one question and one suggestion. Also, be sure to include the license header on all source files and apply the swift formatting (there is a script to help you in ./scriptsformat.sh`)

[natanrolnik]

@sebsto done! I've unified them into two protocols: DecodableRequest and EncodableResponse. Moved tests to a single file accordingly.
About the non-throwing and throwing methods, as we spoke offline, having the two options makes the compiler confused, so I preferred to use the simpler one (non-throwing, with the onError closure that returns a response).

[sebsto]

Thank you or the changes. I still have two quetsions.

[sebsto]

looks like the only difference between APIGAteway's init() and the protocol is the order of the parameters. Unless I missed something else, is there a reason we can't use the existing order for the parameters and delete this piece of code.

[natanrolnik]

You're correct. I thought about changing the order, but it would be a breaking change.

[sebsto]

I agree that we can't change the order on the APIGatewayResponse, but can you change the order on the EncodableResponse protocol ? That way APIGatewayResponse will automatically implement the EncodableResponse protocol.

[sebsto]

Added this init() function to allow this change

[sebsto]

LGTM