Make Lambda handler output for failed requests output errorType as the type of an error rather than FunctionError constant

[benrosen78]

Motivation:

Fix for Issue #580, by making it so that the errorType in failed requests will be the type of the error entity, rather than a hardcoded string of FunctionError. This allows orchestration within step functions that perform retry/catch logic based on different error output types.

Modifications:

At a high level, the issue is that swift-aws-lambda-runtime, when an error is thrown, outputs the errorType as hardcoded to FunctionError. You can see that here:

let errorResponse = ErrorResponse(errorType: Consts.functionError, errorMessage: "\(error)")

This PR changes this for all cases to output the type of the error, rather than the hardcoded string:

let errorResponse = ErrorResponse(errorType: "\(type(of: error))", errorMessage: "\(error)")

Now, I will show 2 examples with this solution:

let runtime = LambdaRuntime {
    (event: Input, context: LambdaContext) in

    enum MyTestErrorType: Error {
        case testError
    }
    
    throw MyTestErrorType.testError
}

// outputs {"errorType":"MyTestErrorType","errorMessage":"testError"}

let dynamoDB: DynamoDB = DynamoDB(client: .init())

let runtime = LambdaRuntime {
    (event: Input, context: LambdaContext) in

    let _ = try await dynamoDB.putItem(DynamoDB.PutItemInput(item: [:], tableName: ""))
    
    return Output()
}

// outputs {"errorType":"AWSClientError","errorMessage":"ValidationError: Length of PutItemInput.tableName (0) is less than minimum allowed value 1."}

[sebsto]

I would add a unit test to be sure custom error errors are reported and we're not going to change this behavior in the future.

[sebsto]

LGTM! Thank you for going the extra mile and adding the test.
If the CI passes, I'll merge and release asap.

Thank you for your first contribution!

[sebsto]

Great !