Redesign how Plugins developer define custom data Archiver

[mattab]

The goal of this issue is to provide a better way for Plugins to define Custom Archiver logic, to make the platform easier to use for ourselves and all third party developers creating custom plugins.

Why is it important?

This refactoring is very important and needed to improve the platform. In this issue we will focus especially on creating a simple meaningful public APIs for plugin's Archiver.php file, and let devs define rules on how data is aggregated, archived, etc.

Other features depend on it: custom dimensions, custom reports depend on custom dimensions, manage apps/server with new custom reports #5257, etc.

• It's possible this refactor would also allow for some performance improvements, for example around date ranges (#4768).

(fyi: here is an example of why refactoring the Archiver is much needed was our recent PR #7468 where had to add a new parameter to the already too long public method. )

Developer guides

Currently the archiver is a bit documented in the Piwik in depth guides: http://developer.piwik.org/guides/archiving and http://developer.piwik.org/guides/archive-data

Ideally, we'd make the guides as simple as possible (as the API become simpler) and we document all that plugin developers need to know in the Develop section.

Timeline

It would be nice to get this done prior to Piwik 3.0.0 as we could then deprecate the older Archiver logic and make it nice.

[tsteur]

Having an easy archiver (ideally plugins do not have to define an Archiver at all!) will be important for #7131 and #4734. This will allow us to easily define new reports for different types.

[mattab]

When solving this issue, it may also help us provide a better developer experience when working with sub-tables, refs: https://github.com/piwik/piwik/issues/6167