fix: add missing aws_iam directive on custom types

[svidgen]

Description of changes

Adds @aws_iam directive to non-model types to support IAM auth from functions and other AWS services.

CDK / CloudFormation Parameters Changed

Issue #, if available

1. IAM not authorized for custom types if default auth mode is not IAM #2929

Description of how you validated changes

1. Updated tests
2. Red/Green access test on EventBridge test app. (Removed the dummy model workaround, observed failure, updated to local build including fix, observed success.)
3. Confirmed async function also still works as expected, per concerns from the linked issue.

Checklist

• PR description included
• yarn test passes
• E2E test run linked (here)
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• Any CDK or CloudFormation parameter changes are called out explicitly

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

[svidgen]

E2E's and PR workflow are still failing in early stages. This has notably been occurring on prior PR's as well and warrants some investigation, which I'll perform prior to continuing with this PR.

[sobolk]

It seems this could be private.
(on the other hand, we never paid a lot of attention to transformers public apis...).

[svidgen]

Yeah. I haven't formed a strong opinion here yet. I'm just following the established pattern for now. 🤷

[sobolk]

I would recommend adopting "if something can be private it should be". that creates less liability going forward. (we've been doing this for a while on backend side).
For transformers it would be more to form a habit (or maybe stop the bleeding) rather than fix them. Their apis are already overexposed.

[sobolk]

This might not be customer facing API. But once exposed and called by some other package on it becomes liability.
An example where versioning "internal apis" matter is here aws-amplify/amplify-backend#2717 (comment) .
(this might not be that important for transformers because api construct locks/bundles them afaik - yet another assumption in the system to excuse ourselves from api versioning...).

[sobolk]

Their apis are already overexposed

This might be a sign that all these transformers packages could have been directories in single package.

[svidgen]

I might agree. And, it all seems pretty chaotic to me at the moment. But, there's also a ton of intrinsic complexity in the problem space. So, I'm attempting to respect what came before and keep as many existing fences erected until I understand them better and have more solid opinions.