publish codegen artifacts to maven central

[aajtodd]

Motivation and Context

Publish codegen artifacts to Maven Central so users can generate Rust clients + servers without cloning smithy-rs and patching our build files.

Description

• Move dependency management to version catalogs
• Move common kotlin and publishing configuration to conventional gradle plugins removing duplication and making a single place to modify this config
• Add jreleaser and configure it for releasing to maven central (this seems to be where everyone is landing, smithy team uses it already and Kotlin SDK is migrating)
• Introduce tasks for checking if a codegen version exists and if gradle.properties has been updated if any codegen project has changed
  • On release it checks if we need to do a publish
  • On PR it checks if we modified codegen projects that we have also bumped the version
• Rename several modules
  • codegen-server/python -> codegen-server/codegen-server-python
  • codegen-server/typescript -> codegen-server/codegen-server-typescript
  • aws/sdk-codegen -> aws/codegen-aws-sdk

TODO

• Need to decide on artifact names. We can probably live with most of them but the python/typescript artifacts don't indicate anything server specific and the sdk-codegen one doesn't indicate "AWS SDK" specific. Generally we don't publish the AWS SDK specific codegen but we tied up a lot of the "AWS specific" stuff like sigv in that module so seems like we might need to publish it as well for it to be of use. Open to discussion though.
• Need to work with @drganjoo on internal testing, in particular need to figure out internal patch file updates needed to land this and versioning scheme
• Need to finish configuring secrets
• Publish GPG keys, for some reason this is still not working I may need to switch machines to try it on
• Complete additional dry run release testing
• Test artifacts and document how to use them in a build script to generate code for generic smithy models

Testing

• Basic testing of gradle tasks done against already published artifacts for other codegenerators, seems to be working but may still need refined
• Test dry run release
  • https://github.com/smithy-lang/smithy-rs/actions/runs/16445373815/job/46479485851

Checklist

• For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "client," "server," or both in the applies_to key.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[landonxjames]

Overall looks good, couple of questions about the python/typescript bindings for the server, but those aren't blockers

[landonxjames]

I know we discussed not publishing the Typescript bindings, but I'm not terribly convinced that we should publish the Python bindings either. I guess people are using them? But my understanding is that support is pretty minimal

[aajtodd]

Probably up to @drganjoo, I'm ok either way as these are all pre-GA versions for codegen with no backwards compat or stability guarantees.

[aajtodd]

The generate diff action is failing. I think this is due to relocating some of the codegen modules and the base version we are merging into has a different path from where we expect it to live. I created a PR to test the workflow from this branch as the base and the diff step succeeds.