[5.1] Fix pagination for group by and having statements

[acasar]

There are two problems that this PR is trying to address:

1.) length-aware pagination with "group by" statements is currently slow since counting of the results is done in PHP instead of in the query
2.) and it's currently not possible to paginate queries containing having statements

In these two cases, we can use a sub query to get the total number of rows:

select count(*) as aggregate from (<original query>) AS aggregate_table

By doing this, we can now paginate any query and it's all done in SQL so it should be a lot faster. If no "groups" or "havings" are defined, then we still use the normal pagination without a subquery. And since we don't need the "hack" for group by statements any more, I was able to clean up some related code as well and defer to the built-in count function in both cases.

This was tested in SQLite and MySQL. Any feedback about other supported grammars is welcome.

[GrahamCampbell]

https://styleci.io/analyses/zEKYAX

[taylorotwell]

Problem with this. Say you have a 1,000,000 record user table. Instead of just running a query like select count(*) from users... now you are running select count(*) from (select * from users) as ...

You are selecting all 1,000,000 rows and loading them up, then counting them. That's not going to be performant.

[acasar]

@taylorotwell Well, until now we were doing the same, just loading them all in PHP and counting them there. I think this is still much better.

And once again - it doesn't change anything if you don't have "group by" or "having" statements - in these cases a normal select count(*) from users... is executed. This PR just takes care of some edge cases which didn't work before (having statements) and improves performance for "group by" statements.

[taylorotwell]

No, that's not what we're doing right now. Here are the two queries generated from User::paginate() out of the box:

"select count(*) as aggregate from `users`"
"select * from `users` limit 15 offset 0"

[taylorotwell]

You can see that we're just doing a count, we're not actually pulling back the entire users table.

[acasar]

And that still remains the same. Try adding a group by and see what happens now vs. after.

[acasar]

Again - for the case above, nothing has changed.

[acasar]

@taylorotwell I made some benchmarks on a table with 100,000 rows and I ran the following query 100 times:

EloquentTestUser::groupBy('email')->getQuery()->getCountForPagination()

The results show that with this PR it's about 20% faster.

Without PR: 12.6s, 12.9s
With PR: 10,7s, 10,6s

[tylercrompton]

Which database did you use? Did you try others. The results are possibly very implementation-specific.

[coveralls]

Changes Unknown when pulling 85f3352 on acasar:fix-pagination into ** on laravel:5.1**.