Remove dependency on ModelRegistry for syncability of models

[lawmicha]

Major changes

This introduces a flag for whether a GraphQLDocument helper method should contain the sync-able fields. Methods like GraphQLSyncQuery by default will be true, and methods like GraphQLGetQuery can be used with syncEnabled parameter.

Minor changes

• Moved MinimalGraphQLDeleteMutation over to PluginsCore as GraphQLDeleteSyncMutation
• Updated GraphQLListQuery to include limit and nextToken, in anticipation for ModelBased List query to allow limit/nextToken.

Testing done

• Ensured the Sync provisioned backend in API integration tests is working as expected, and so went to datastore plugin and updated the calls where necessary, like

let document = GraphQLSubscription(of: modelType,
                                   type: subscriptionType,
                                   syncEnabled: true)
// adding syncEnabled true parameter

• Ensure Model based APIs are working. by default the models are not syncable until specified to be syncable. since Model based API's should never be used with sync and developer should use DataStore if using sync provisioned backend

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

[palpatim]

My read on this is that syncability is an internal concept, which seems appropriate. The way we're representing it seems odd to me--why do some types have separate "Sync" flavors, while others are extended by virtue of an incoming boolean parameter? I'd like us to think a little more about this to see if this is the right way to model it. But as an incremental change to enable the functionality for now, LGTM.

[palpatim]

Is createPost creating a Post model or a CreatePost mutation? Please align the names appropriately

[lawmicha]

updating to createdPost

[wooj2]

Also okay with pushing this in.. we can talk about the interface for subscribe at a later time

[wooj2]

I'm not sure if it makes sense to expose a syncEnabled flag for this class, right? Seems like if we have a subscription with a model, syncEnabled has to be true, right?

[lawmicha]

a backend can be provisioned with/without sync so the graphql document can be constructed with sync related fields or without by using this syncEnabled parameter

[lawmicha]

My read on this is that syncability is an internal concept, which seems appropriate. The way we're representing it seems odd to me--why do some types have separate "Sync" flavors, while others are extended by virtue of an incoming boolean parameter? I'd like us to think a little more about this to see if this is the right way to model it. But as an incremental change to enable the functionality for now, LGTM.

Yes I agree, it is odd that there are specific types to build in the sync fields and then there are types that just take in the syncEnabled parameter. I can see these types getting another overhaul, especially with the @auth directive.