fix(adapter-commons): Clarify adapter query filtering

[daffl]

This pull request tries to address some inconsistencies and flexibility issues when implementing and using database adapter.

The problem

There are several issues that mention a lack of clarity when using the previous filterQuery method. What is a filter and what isn't? How are they customized? Another recurring problem is that you may not want strict query filtering when using a database adapter on the server.

Improvements

Remove filterQuery and add sanitizeQuery and sanitizeData

This pull request removes the filterQuery adapter base service method and adds a sanitizeQuery and sanitizeData method instead. sanitizeQuery applies the previous query filters but then returns them as a single query object and it is up to the adapter implementation what to do with that. sanitizeData does nothing by default but could be used to e.g. filter out protected fields (or things like $push for MongoDB).

Add $ prefixed unsafe internal service methods

It also changes the semantics of the _find, _get, _patch, _update and _remove internal (hook-less) service methods to sanitize the query and data and check if multi updates are allowed. It has been moved from the service methods so that it is easier to extend from a database adapter and implement the service methods you need instead of being limited by a type interface (also see #2605).

For better flexibility, it additionally introduces the $find, $get, $patch, $update and $remove unsafe internal service methods. This is what a database adapter now implements and it shouldn't do any query or data sanitization. Calling these methods directly lets you do any query the database adapter supports without having to explicitly declare allowed operators, filters or multi settings.

Clarify filters and operators

Finally all parts of this PR follow a more strict definition of filters and operators:

• A filter is a special top level query property starting with a $. This can be used for pagination ($limit, $skip), modifying the result set (e.g. { $populate: true } etc.
• An operator is a special property starting with a $ that can be used to query properties, e.g. { age: { $gte: 21 } }

This definition has also been reflected in the Querying API documentation.

The adapter settings have been updated and can now be used like this:

service({
  filters: {
    $populate: true,
    $ignoreCase: value => value === 'true' || value === true ? true : false
  },
  operators: [ '$eq' ] // allows `{ name: { $eq: 'David' } }`
});

Ideally I'd like to see a lot of this responsibility moving to using a query schema and resolvers instead which can handle all those complexities (type coercion, setting dynamic properties etc.) much more cleanly and securely but this is hopefully a step in a better direction.

• Closes About filterQuery #1161
• Closes [adapter-commons] filters and operators #2389
• Closes [Suggestion] Apply operator whitelist option only for "external" provider by default #2445
• Closes [Suggestion] ability to allow multi queries for internal calls only #2546
• Closes Suggestion: Have whitelist_client and whitelist_server instead of whitelist #2550

[matiaslopezd]

ref #1161