Support pagination offset/limit

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 🐛 Protect pager against [] for the page Needs work 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.