* Improve serialize dataTable performance

This seems to improve the performance of serializing a data table which is useful when archiving. In my case it made the archiving of a monthly archive twice as fast from about 120 seconds down to like 70seconds.

* remove no longer needed variable

* faster check whether an array key is set

It is known that array_key_exists is quite a bit slower than `isset`. As this is executed easily a few million times this makes a difference in performance but here `array_key_exists` and `isset` work the same in logic as we never set `$consecutiveSubtableIds[$id]=null`

* Assignment should be no longer needed as passing by reference

There is no need to recursively iterate over all dataTables, when there is no column to rename.

* Minor changes to wording

* Add a mention to the InvalideReports plugin

As long as it does not create performance regression or impact, it would be really useful to have this by default in Piwik, makes it useful to troubleshoot archiving problems without having to patch this file and uncomment this logger line.

If you're using Piwik behind a reverse proxy with a different path like "rewrite ^/piwik/(.*)$ /$1 break;" (nginx.conf), you can provide a header "proxy_set_header    X-Forwarded-Uri /piwik;" which will be considered to the current script name. (#12011)

It's necessary, because the redirect after login and links e.g. the logo are not working correctly without.

* fixes #12201 add possibility to change text color in header

* fix screenshot

* fix typo in changelog

* use composer version of geoip library

* region london was renamend in latest geoip version

* Handle actions with title only correctly

* use action with empty url for tests

* update expected ui files

* Issue the CORS header (Access-Control-Allow-Origin) also on Tracking API requests

* Move CORS code to the Tracking API endpoint file

* Adds a note about cross domain linking requiring multiple domains. Adds a new i18n key CoreAdminHome_JSTracking_CrossDomain_NeedsMultipleDomains

* Update en.json

* Make all new segments "Pre-processed" when browser_archiving_disabled_enforce=1

If real time processing of segments is disabled via browser_archiving_disabled_enforce=1
then any segment set to "segmented reports are processed in real time (default)"
will NEVER be showing data (except in the Live/real time reports)

With this PR all new segments will be set to "segmented reports are pre-processed (requires cron)"

It does not fix up existing real segments, but existing real time segments would display a modal explaining the issue (refs https://github.com/piwik/piwik/issues/12253)

* Re-use existing method

* Re-use existing method

* Introduce config setting to show update notifications to superusers only. Fixes #7930

* By default, all users should see the update notification

* Changed description of config param

* Updates changelog

* make HTML in safemode-page valid

* update UI test

Otherwise the topbar will be always hidden as there is no text for it. Only affects demo.piwik.org

To make sure as many tracking requests will be tracked as possible eg on "unload" of the page. Did not test it specifically but shouldn't cause any trouble.

Add visitor details events

Similar to Report.add/filterReports, Widget.add/filterWidgets, etc

We can change naming but kept it consistent with these existing events. It may be a bit confusing to have `Live.addVisitorDetails` and `Live.filterVisitorDetails` vs `Live.getAllVisitorDetails`. For `Live.getAllVisitorDetails` you would then expect it returns maybe all visitor detail instances. The first 2 work basically on the raw instances, whereas `Live.getAllVisitorDetails` works on the actual visitor details data. Any thoughts @sgiehl ?

added $_COOKIE to RequestSet environment