Draft: Connect to be deleted to consent

Reading Art. 17 GDPR again, I realized that there really is no general "right to be forgotten". Instead, this article explains under which conditions you can request deletion. The most relevant case for us is probably when a subject revokes their consent.

Since storage is a kind of processing, I had assumed that revoking consent implies that my data can also no longer be stored. But apparently, revoking consent only means that no new data can be added. If I also want existing data to be deleted, I have to request it explicitly. I am not 100% sure on this, but that is what I gathered from Art. 17.

Our "to be deleted" field inherits some of the confusion from Art. 17. It's not entirely clear when this field should be used, how an organization should react when it is used, and how it is different from revoking consent.

My idea here is to integrate "to be deleted" with the consent UI, making more explicit that the two are connected. From the user's perspective, this removes some awkward validation (see for example !2532 (merged)). From a code perspective, this is unfortunately a little bit more complicated because to_be_deleted is not actually part of the consent model.

Another consequence of model mismatch is that to_be_deleted is not included in the consent history (see !2512 (merged)).