Background

This PR is coming from feathersjs-ecosystem/feathers-sequelize#364 and feathersjs-ecosystem/feathers-sequelize#363 . It's a discussion between me, @daffl
and @DaddyWarbucks if, on a service with default pagination, a patch:multi without any paginate in params should patch only a subset of items (default pagination) or all items (paginate: false). The same applies to remove:multi.

In my opinion there are two points:

1. What is the most anticipated behavior? How many items do you expect to patch, when you do something like service.patch(null, { isConfirmed: true }, { query: { canBeConfirmed: true, isConfirmed: false }}? All items that fulfill this criteria or a maximum of 10 items (most default pagination). Default pagination for find method is a no-brainer, because the structure changes from { data, skip, total } to any[] and you can check wether data.length is the same as total. For patch:multi and remove:multi you only have any[] either way. You don't know, if you patched/removed all items or not. This is a point for paginate: false as default for patch:multi and remove:multi
2. For patch:multi and remove:multi sometimes you want to find all items that will be changed/removed. I need that in my applications for permissions, changelogs (need to know the old value before the change). So I would expect that a find and a patch/remove return the exact same items. This is a point for paginate.default as default for patch.multi and remove:multi

As point 1 as for paginate: false, point 2 is stronger to me. Either way I'll add a hook to my app.hooks.js file that ensures the same pagination behavior for find, patch:multi and remove:multi

Solution

While the discussion for or against paginate: false as default for patch:multi and remove:multi is somewhat ongoing., we should ensure that all adapters act the same. That's where this PR comes into play. I added a standardized adapter-test to check this behavior. As feathers-sequelize has paginate.default as default patch:multi and remove:multi, the test exactly checks against this behavior. I added the test to the internal @feathersjs/memory and it fails because getEntries is used in _patch which uses paginate: false by default. So the behavior of feathers-sequelize and feathers-memory is different in this case.

I also added typings for @feathersjs/adapter-tests with AdapterTestName replacing string to prevent typos.

Todos:

• Decide wether paginate: false or paginate.default should be the default behavior. @daffl
• When the behavior is clear, change the test to ensure this behavior @fratzinger
• Add the test to @feathersjs/memory (currently paginate: false overwrites anything confirmed) @fratzinger
• Add a note in docs for patch:multi and remove:multi so it's clear for everybody @fratzinger not needed for no pagination - since it's intuitive
• Add a test for remove:multi @fratzinger
• Release a new adapter-tests package @daffl
• Add the tests to feathers-sequelize (currently paginate.default does not overwrite anything confirmed) @fratzinger
• Add the tests to feathers-objection (currently paginate.default does not overwrite anything first glance) @fratzinger
• Add the tests to feathers-knex (currently paginate: false overwrites anything first glance) @fratzinger
• Add the tests to feathers-mongoose (currently paginate: false overwrites anything first glance) @fratzinger
• Add the tests to feathers-mongodb (currently paginate: false overwrites anything first glance) @fratzinger
• Add the tests to feathers-nedb (currently paginate: false overwrites anything first glance) @fratzinger
• Add a hook to feathers-hooks-common to ensure the same behavior for find, patch:multi and remove:multi @fratzinger not needed