Codegen aws-sdk-go-v2 clients

[tinnywang]

Summary

Add support for generating our own bespoke ECS client that's compatible with aws-sdk-go-v2.

Implementation details

aws-sdk-go-v2 uses the Smithy Gradle plugin to generate client code.

At a high level, the SDK

1. generates smithy-build.json files for every JSON model in the aws-models directory
2. generates clients from the definitions in the smithy-build.json files
3. copies the generated clients from the Smithy build directory into service directories and generates go.mod files for each service package

We simulate this process by building a Docker image with

1. Go >= 1.20 (needed by smithy-go)
2. Java >= 17 (needed by Gradle)
3. the smithy-go Gradle plugin
4. the aws-sdk-go-v2 repo

and then volume mounting the aws-sdk-go-v2/aws-models and aws-sdk-go-v2/service directories to the container. When the container runs, it reads the JSON models from aws-sdk-go-v2/aws-models and writes the generated client code and go.mod files to packages in aws-sdk-go-v2/service.

Notes

• The aws-sdk-go-v2/aws-models directory currently contains our bespoke ecs.json model. If we need more custom clients in the future, we add their JSON models to this directory.
• The aws-sdk-go-v2/service directory only contains an ecs package since we currently only generate an ECS client.
• To generate clients, run make gogenerate-aws-sdk.
• Differences between our ecs package and the SDK's:
  • Some input/output types have additional fields. These additions were ported over from our existing bespoke models.
  • The SDK's go.mod uses replace directives to reference other modules in the repo. Ours does not because, while our clients are customized, their dependencies should still be the official SDK modules.
• Generated clients must be in their own go modules with paths like github.com/aws/aws-sdk-go-v2/service/${service} because they import packages internal to github.com/aws/aws-sdk-go-v2.
• Our ecs-agent and agent go modules will eventually use our bespoke ECS client by depending on our local aws-sdk-go-v2/service/ecs module. They should continue depending on official aws-sdk-go-v2 modules for everything else, however. This can be accomplished with replace directives, e.g.

require(
    github.com/aws/aws-sdk-go-v2 v1.31.0
    github.com/aws/aws-sdk-go-v2/service/s3 v1.63.1
    ...
)

replace github.com/aws/aws-sdk-go-v2/service/ecs => ../aws-sdk-go-v2/service/ecs

Testing

This PR only includes codegen changes and the generated ECS client. The client is not used anywhere yet.

In a separate branch, I have replaced our aws-sdk-go ECS client with our bespoke aws-sdk-go-v2 ECS client and tested that everything compiles.

New tests cover the changes: no

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sparrc]

JDK 17 is pretty old at this point, since this is a new dockerfile is there any reason we cant use something newer? Would jdk-23 work?

[tinnywang]

Updated it to install OpenJDK 23 via Amazon Coretto in 9685bbf (the base image is Debian Bookworm, which doesn't support anything newer than OpenJDK 17).