fix: Lambda client env var name issue

[stocaaro]

Problem

When using the getAmplifyDataClientConfig function with a named dataBackend, the SSM variable names don't line up.

Example:

export const data = defineData({
  name: 'CoolName',
  schema,
  ...
})

with

// amplify/auth/post-confirmation/handler.ts
...
import { getAmplifyDataClientConfig } from '@aws-amplify/backend/function/runtime';
...

Results in a typescript error caused by mismatched env var names.

Issue number, if available:
#2320

Changes

• Use AmplifyData as a prefix (which is included even if a user defined name is provided
• Always pass the name and prefix through the AMPLIFY_DATA_DEFAULT_NAME SSM variable
• getAmplifyDataClientConfig now uses the default name variable to use the correct env variables
• Move toScreamingSnakeCase into the export surface of '@aws-amplify/platform-core' as SSM variables are normalized by this method and this normalization needs to be applied to consume these variables in getAmplifyDataClientConfig

Validation

• Modified integ test to use defineData({name: '', ...})
• Add unit tests to cover the named case
• Manual validation

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

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

[changeset-bot]

🦋 Changeset detected

Latest commit: c14ab2c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@aws-amplify/backend-function	Minor
@aws-amplify/backend-data	Patch
@aws-amplify/platform-core	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Amplifiyer]

will this not create a duplicate when namePrefix is empty?

[stocaaro]

I was worried about the same thing. Up on line 311, name prefix is left blank if the name is defaulted.

[Amplifiyer]

If it's not expected, we should avoid adding it. Also wanted to ask what's special about GRAPHQL_ENDPOINT that this behavior is not replicated for the other _MODEL_INTROSPECTION_SCHEMA_BUCKET_NAME and _MODEL_INTROSPECTION_SCHEMA_KEY

[stocaaro]

GRAPHQL_ENDPOINT predates the MIS fields and customers may be depending on it directly. Since the other two are newer, @sobolk advised that they can be modified without concern for breaking change.

Also GRAPHQL_ENDPOINT is included in the prefixing, however, we are leaving an unprefixed version in place with a @Deprecation flag to enable removal with the next major version change.

[sobolk]

Suggested change

	const ssmEnvironmentScopeContext = {
	const ssmEnvironmentEntries = {

perhaps. this is a nit, feel free to ignore.

[stocaaro]

This naming came from the function that receives these entries/vars ssmEnvironmentEntriesGenerator.generateSsmEnvironmentEntries(scopeContext). I'm going to proceed with this naming and can revisit it in another change if we decide its clearer with different naming.

[sobolk]

update this plz if you take above nit.