fix: add aws_iam to custom operations when enableIamAuthorization is enabled

[palpatim]

Description of changes

• Add aws_iam to custom operations when enableIamAuthorization is enabled. Fixes Custom mutation not accessible with IAM #2837
• Fix graphql type utils -- previously the return types of some type predicates were incorrectly grouped

Merge conflicts

• packages/amplify-graphql-transformer-core/API.md
  • Regenerated

Issue #, if available

#2837

• Note: This PR leaves IAM not authorized for custom types if default auth mode is not IAM #2929 unfixed. See that issue for discussion.

Description of how you validated changes

Checklist

• PR description included
• yarn test passes
• E2E test run linked
  • Passes
  • Test schema_auth_15 fails because the prompt handling for that test hasn't been updated to reflect the new CLI Gen 1 prompts as in test: fix gen 1 init #2924. Fixed in 5965fab
  • Test RelationalWithAuthV2Redacted.e2e.test.ts fails b/c of known bucket naming conflict. Passes locally
• Tests are changed or added

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

[atierian]

From what I can tell this is adding @aws_iam to operations, but not to any types those operations may return. In Gen2 world, I'm thinking about this scenario:

const schema = a.schema({
  Foo: a.customType({
    bar: a.string()
  }),
  myFooQuery: a.query()
    // ..
    .returns(a.ref(Foo)),
});

type Foo { 
  bar: String
} # does this have @aws_iam?

type Query {
  myFooQuery: Foo @aws_iam
}

Do those types already have @aws_iam / am I missing something in this PR / is it planned in a follow up?

[atierian]

nit

Suggested change

	const makeAwsIamDirective = (): DirectiveNode => {
	return {
	kind: 'Directive',
	name: {
	kind: 'Name',
	value: 'aws_iam',
	},
	};
	};
	const makeAwsIamDirective = () => makeDirective('aws_iam', []);

[palpatim]

TIL! Will fix

[palpatim]

@atierian - Decided to promote the existing fix for scalar return values, and opened #2929 to track the complex custom type issue. Thanks for pointing that out!

[palpatim]

Converting this to draft while we figure out the right way of implementing automatically decorating custom return types, as in:

type Foo {
  description: String
}
type Query {
  getFooCustom: Foo
}

[palpatim]

Will also discuss whether we want to just release this fix as-is, to support custom operations that return scalars. We can then take on custom operations that return non-model types.

[palpatim]

Decided to release this fix for scalar return values, and opened #2929 to track the complex custom type issue.

[phani-srikar]

nit: We already have a centralized directive existence checker on Object types defined in the common package, we could add one for field types so it is re-usable across transformers

[palpatim]

Thanks, will address in a followup PR!

[palpatim]

note: this should be private. Will make it so in a future PR, which will remove it from the published API. Since the transformer interface isn't actually used by customers, this won't be a breaking change