Fix piwik statistics

[kosarko]

Items submitted after 2020-05-15 show no views in the piwik-statistics tab (and the item submitted on 2020-05-15 (ud 2.6) shows views only until may 29th)

For lindat repository the fix must happen in https://github.com/ufal/lindat_piwik_reports as we use that for caching the results.

I suspect the issue is there also for the "non-cached" version. I believe the underlying issue is an update to piwik >=3.12.0, which "fixes" the behavior of segments (matomo-org/matomo#11900, also see https://forum.matomo.org/t/filter-page-urls-by-segments/34859/8 and especially https://forum.matomo.org/t/filter-page-urls-by-segments/34859/2). 3.12 was released in Nov 2019; not sure when we've updated
I believe this non-cached version should* at least return some numbers, however, these will be meaningless (as it would sum the hits/visits across a segment**, not just filtered to one item page).
* it takes a lot of time to produce the result, so it may actually timeout.
** ie. it will be the visits/hits of all the pages a user, who visited repository item page in question, has visited

[kosarko]

1. Bitstream downloads include bots (this is probably due to Include browser user agent in download statistics piwik request and make it configurable #438, the user agent is not send by dspace).
2. The numbers displayed in dspace might be meaningless anyway; as the piwik config currently has datatable_archiving_maximum_rows_subtable_actions = 100, see https://matomo.org/faq/how-to/faq_54/, in essence this means that if the item is not popular enough in particular year/month/week/day they will be archived in 'other' slot and won't be in the api response; this also means you might get different total numbers based on the period (y/m/w/d) you ask for (on the year level the "competition" for the available slots is much higher than on the day level). Maybe https://github.com/ufal/lindat_piwik_reports was meant to solve that, but does it?