introduce data aggregation (#194)

[stklcode]

We add a new column named hits to the database table with default value of 1.
The tracking routine is preserved as is, i.e. it will insert a single row per hit.

The cleanup routine (cron job) is extended with an aggregation function that walks through the database and groups distinct date/referrer/target combinations with the sum of all hits.

before:

created	referrer	target	hits
2022-09-07	example.com	/	1
2022-09-07	pluginkollektiv.org	/test/	1
2022-09-07	example.com	/	1
2022-09-07	example.com	/	1
2022-09-08	pluginkollektiv.org	/test/	1
2022-09-08	pluginkollektiv.org	/	1

after:

created	referrer	target	hits
2022-09-07	example.com	/	3
2022-09-07	pluginkollektiv.org	/test/	1
2022-09-08	pluginkollektiv.org	/test/	1
2022-09-08	pluginkollektiv.org	/	1

The output is generated from SUM(hits) instead of COUNT(*) then.

We also introduce a boolean book statify__skip_aggregation (defaults to false) to keep the previous behavior and disable the new aggregation.

This might be necessary if the inserted entry is extended with custom columns, e.g. in a statify__visit_saved hook. If this is the case, aggregation will fail, because we don't know about additional columns. We could of course add another hook for custom aggregation columns and dynamically build up the statements, but for most users this won't be necessary and it can be extended in future releases as well.

[patrickrobrecht]

These changes would require changes to keep the functionality of Statify - Extended Evaluation, but hopefully helps to improve the performance with large Statify tables (I've installs with 1,000,000+ entries): patrickrobrecht/extended-evaluation-for-statify#29.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

No Coverage information
0.0% Duplication

[stklcode]

As previously discussed in various places this feature might need some additional planning.

• With planned additional data collection (probably even dynamically extensible) this might require constant refactoring.
• Is database size really still an issue so that it's worth the effort?
• Probably drop this idea in favor of maybe some more elaborate caching of evaluation.