Support pagination offset / limit parameters

Bump patch #4 to work with release 1.0

With PHP 8.x I had to install the patch at https://www.drupal.org/project/drupal/issues/3143617 to avoid an error.

The suggested patch in #5 does not work in Drupal 10 due to symfony's ->get() method on the input bag. The input bag now requires the returned data to be a scalar (string, number, boolean, etc). But switching to use the ->all() method further breaks due to the Drupal core's view loads the pager via this line in PagerParameters. The patch mentioned in #6 and 7 does not help because it uses the same ->get() method and throws the same error, just in a different place.

The patch is working fine with 9.5.11, but the total count is not correct, since it returns the items per page + 1.

Does it make sense to use $view->total_rows to populate the count property in meta?

I correct myself in #8 (unless it was some dependency update I needed). I've attached the patch that works for me with Drupal 10.1.4.

@noemi, I wasn't able to reproduce your incorrect count. If I set `?page[limit]=5` the returned number in the meta is 5. What could be more helpful is to have a "total" returned as well. But I wasn't able to find a quick solution for that.

@pookmish I realized the problem with the count is not directly related to this issue, but the use of an offset.
In short, the total count is equal to the count + the offset and maybe this is the expected behavior.

I'm getting this TypeError: explode(): Argument #2 ($string) must be of type string, array given in explode() error from PagerParameters.php.

The latest patch/diff from https://www.drupal.org/project/drupal/issues/3143617 will not accept page[number] and/or page[limit] query.

This patch added a "views_" prefix to the OffsetPage:KEY_NAME to avoid conflicts with the page key. So we can use views_page[number] and views_page[limit] instead.

Here's another patch, following the other query args like views-filter, changing views_page to views-page query args. So it will be views-page[number] and views-page[limit].

Also adding the new query args to the cache contexts.

Patch #13 works for me

When I use for example 100: &views-page[number]=0&views-page[limit]=100 I'm getting 42 results, but if I use lower numbers for limit parameter like 5, 10 or 20, number of results are more consistent. Maybe it's a timeout.

Maybe someone could prepare a MR from this? I agree this is typically very helpful!

I turned #10 and #13 then into a MR to push things forward here. Corrected code style. Anyone willing to test and review?

#3292906: Meta should include information about the view should then get solved as follow-up in combination.

We should ensure unification for the parameters used!
For that we should look for global defaults (REST / JSON:API in general, in and outside of Drupal) and in core and other modules like:

https://www.drupal.org/project/jsonapi_extras:

Integrations

The JSON:API Defaults sub-module allows you to specify default input parameters (include, page[limit] and filter) for your resource collections.

Below is the combined branch for #23

https://git.drupalcode.org/project/jsonapi_views/-/merge_requests/21.diff
https://git.drupalcode.org/project/jsonapi_views/-/merge_requests/21