fix(api-graphql): custom operation selection set on nested custom types

[HuiSF]

Description of changes

• Updated custom operation impl. to use pre-existing selection set generation utility function so it can handle nested custom types
• Added unit tests against the nested custom types scenarios
• Bump data schema packages versions to gain new implementations

Issue #, if available

Description of how you validated changes

1. unit tests
2. manual E2E tests in a sample app

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

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

[stocaaro]

Makes sense. I think all of the below are more nit than concern. Good to see this ship as is or with any attention to these comments.

[stocaaro]

Exporting the default function to call it in passed into IRToString function makes me wonder if it would be better to export a function that combines the two functions instead of stacking the calls here.

[stocaaro]

I'm a fan of grouping utils up into folders like this. Would it be valuable to have a folder level index that exports the sub-types instead of deep referencing them?

[stocaaro]

We're wrapping strings in surrounding curly brackets, {}, in several places. I find the character sequence `{${ a bit hard to read, which makes me wonder if a few extra chars for wrapInCurlyBrackets(x) might be more readable.

Not specific to this PR, but a thing I thought of.

[iartemiev]

LGTM.
As Aaron suggested, would be nice to import from a top-level utils/index.ts instead of sub-dirs, but that's non-blocking

[HuiSF]

Thanks if this is non-blocking I will open a separate PR to refactor further (also wanted to extra the selection set utils out from that long source file)