refactor: allow JS resolvers with S3 assets

[atierian]

Important

No snapshots were harmed in the making of this PR.
No behavioral changes are included in this PR. This is prerequisite work to allow S3 asset JS resolver functions.

This is followup work to #2812.

Description of changes

• Adds a few types to represent VTL and JS runtime mapping templates (reference).

export type VTLRuntimeTemplate = { requestMappingTemplate: MappingTemplateProvider; responseMappingTemplate: MappingTemplateProvider };
export type JSRuntimeTemplate = { codeMappingTemplate: MappingTemplateProvider };
export type FunctionRuntimeTemplate = VTLRuntimeTemplate | JSRuntimeTemplate;

• Removes addToSlot from exported TransformerResolverProvider interface in favor of addVtlFunctionToSlot and addJsFunctionToSlot (reference)

• Adds S3MappingJSResolverFunctionCode class for JS runtime specific S3MappingTemplateProvider (reference)

• Adds MappingTemplate.s3MappingFunctionCodeFromString function to allow creation of (S3) asset based JS runtime resolver functions. (reference)

• Updates TransformerResolver constructor and internal functions to accept new FunctionRuntimeTemplate type.

• Updates callsites in various transformers to new addVtlFunctionToSlot, addJsFunctionToSlot functions See commits for individual changes made to each transformer.

• Updates conversation and generation transformers to use JSRuntimeTemplate.

Note

I recommend conducting a very surface level review of the conversation and generation changes. This PR is a prerequisite to two follow up PRs (for conversation and generation respectively) that migrate to using S3 asset based resolver functions. The majority of the conversation and generation transformer specific changes in this PR are again changed in these subsequent PRs. This was done to isolate the changes in the PR as much as possible, while not breaking the conversation and generation transformers.

CDK / CloudFormation Parameters Changed

N/A

Issue #, if available

N/A

Description of how you validated changes

• PR workflow
• E2E workflow

Checklist

• PR description included
• yarn test passes
• 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.

[atierian]

This function implementation could benefit from splitting things out in a cleaner way. A part of me feels bad for tacking on more runtime specific conditional checks here. But a bigger part wanted to keep the scope of this (already large) PR to a minimum.

[atierian]

As far as I can tell, the instanceof InlineTemplate check conducted for VTL resolvers below isn't a valid conditional for determining if a mapping template is inline or not. I'm not comfortable changing the behavior for VTL resolvers because I assume downstream things are depending on this behavior. But JS resolvers are a new concept here, so this is doing the "correct" check. Hence the discrepancy in conditionals between JS and VTL mapping templates.

[phani-srikar]

If we're disambiguating the runtime by introducing new runtime specific methods, do we still need this argument?

[atierian]

Good call, thanks. I removed them from the TransformHostProvider functions already, but missed them here. Addressed in 27f4ea1

[phani-srikar]

same here: should we let this method handle the runtime setting internally?

[atierian]

Addressed in 27f4ea1