[gdpr] What data should be included in a user download feature

For the [Discourse Legal Tools Plugin](https://meta.discourse.org/t/legal-tools-plugin/87966) we took a "maximalist" approach to what data should be included in a download of user data for the purposes of data portability and access.

I created a class that looped through lists of columns for each table which were then used to cumulatively add data to an object that was than bundled as a csv file. This piggy backed off of, and expanded, the existing Discourse user data download feature. The lists of columns included in the download are [here](https://github.com/paviliondev/discourse-legal-tools/blob/master/lib/export_csv_file_extension.rb#L59). Those lists serve as a decent reference list for the same in Flarum.

In terms of the thinking behind the approach taken here, I would highlight the reasoning I laid out [here](https://meta.discourse.org/t/legal-tools-plugin/87966/5?u=angus), which I've copied below so we can discuss them further in the Flarum context.

-------------

I would emphasise “for the purposes of this feature”, as the purpose of this feature is to take a ‘maximalist’ approach to possible interpretations of the GDPR. It does not attempt to parse ‘likely’ approaches. I’ve laid out some of my own views on the ‘likely’ approaches in [this topic](https://meta.discourse.org/t/providing-data-for-gdpr/83595) (which remain unchanged).

The specifics of the reasoning behind this ‘maximalist’ approach are:

- The broadest interpretation of A.4.1 (the definition of ‘Personal Data’ in the GDPR) as it applies to Discourse is any record in the db that contains the user’s user_id, i.e.:

> any information … identified or identifiable natural person … identified, directly or indirectly, in particular by reference to … an identification number

- Read literally, this definition doesn’t care about how the data is produced (e.g. whether the user is acting or not). It merely requires the data to be related to the user’s identifier in some way.

- However, applying that literally would produce a fair amount of duplication (e.g. the records in the directory_items table are duplicative of various other entries).

- The point of the extended download is to guard against even the small risk that Article 4.1 could receive a very broad interpretation by some authority or court in Europe.

- The factors against including it - size of download, potentially security (?) - do not outweigh the possible benefit of including it.

We also considered whether to include ‘administrative’ records with the user’s user_id such as flags, complaints and staff whispers. We decided against this, reasoning as follows:

- They’re already in the territory of information associated with the user purely by their identifier. They are not information about the user per se (i.e. name, email, age, location etc). This is already assuming a wide interpretation of A.4.1.

- Whether administrative records intrude on the privacy of other parties, or other relevant concerns (i.e. R. 63.5 & A.15.4) must be determined on a case-by-case basis.

- Other parties, such as Facebook, do no include such data in their user download functionality.