Create "queriers" and promote "mutators" as the preferred way to get data server-side instead of the connector

[eric-burel]

Is your feature request related to a problem? Please describe.
The connector is meant for database communication, as an ORM.
But it cannot include Vulcan security checks.
Describe the solution you'd like

• Create "queriers", similar to "mutators", that get the data + run basic security check. See example of the user API route: it doesn't respect permissions because its bypassing permission filtering. Mutators/queriers are the default way to get standard data, connector should only be used for custom mutations/resolvers
• Make the syntax more attractive, for instance expose closures within the model so  createMutator({ model: Users,...}) becomes Users.create = (params) => createMutator({model: Users, ...params}). Same goes for hooks by the way (useMulti<UserType>({model: "Users"}) => useMultiUsers(...).

Describe alternatives you've considered
Putting callbacks within the connector, at the db level. But that will never be sufficient, as the connector is always specific to the underlying technology.
Mutators are the right place to do "generic" checks, like checking Vulcan permissions.

Connector should only be used when creating a custom mutation/resolver, that do not fit the basic crud operations.

For instance, see account management feature: we use the UserConnector, and StorableTokenConnector => we should use "queriers" and "mutators" instead so that callbacks are correctly applied.

[eric-burel]

After more investigation:

• we are supposed to use "DataSources" in order to have the best performances for a request
• DataSources must be recreated on a per request basis
• They have to be defined in user land, we cannot create them automatically => that's because the user is responsible for implementing any custom method that will let them use the underlying Mongo collection as they want.
  We will have to figure how to include them in Vulcan: should they be passed to the "Connector" for instance? A datasource has to know the underlying db so probably yes
• They have to be passed to "mutators" and "queriers" => even when there is no request context per se, for instance when seeding the data or when creating a raw Express server, we should still be able to create a Graphql-like context. This context is extremely useful to have a consistent code, and performant Mongo access via data sources (eventhough this is less necessary in Express, a complex endpoint might still benefit from such optimization).

[eric-burel]

DataSources and connectors will be soon better supported.
The "queriers" might reuse the "createContext" method to generate a valid graphql context internally. They probably should not use the "dataSources", but only the connector of the model.

/!\ Right now the default connector (Mongo) is added in "api/graphql.ts" => we should figure a way to provide a helper in "@vulcanjs/mongo-apollo" to create models that directly have this connector?