Extend deletion configuration for field-wise deletion

[MartinWahnschaffe]

Situation Description

7008 introduces a configuration for automatic deletion of entities. Besides this we also need to be able to delete data of individual fields.

Pre-requisite #7760

Feature Description

• [ ] Extend the FeatureConfiguration with an optional field called "fields" that is a list of field paths that are supposed to be deleted.

Since the whole logic and the data dictionary are based on the dtos and not the entities, these field paths are relying on the dto as-well.

An example for a field path would be "symptoms.bloodPressureDiastolic" to delete the diastolic blood pressure information of a case (CaseDataDto).

Important: We only allow to delete the value of fields that are either native data types (int, string, enum) or ReferenceDto and are NOT required. Using the Dto instead of directly deleting in the entity or the database has the benefit of validating the dto when saving it.

Next we need to update the deletion process executed by the cron service. When fields are defined, the following needs to be done

• [ ] Load the related entity dto. Use reflection to set all defined fields to null or 0. Then save the entity.
• [ ] If the field path contains a list (e.g. epiData.exposures.exposureType), the value has to be deleted for all entries in the list.
• [ ] Cache the reflection information

Also implement a validation for the configuration that can be executed whenever a configuration changes.

• [ ] Output warnings in the log for every field deletion rule that is not matched by a deletable field in the dto. This goes for fields that are: a list, an entity, don't have a setter, are not matched by an entity field (e.g. are calculated. See #7760).
• [ ] Also output warnings in the log for every field that is a required field and thus can't be deleted (because the whole entity would have to be deleted).

Out of scope

Important: The field-wise deletion implemented here should not cover related persons and visits. Those can be referenced by multiple different core entities with different field-wise deletion rules, so a more complex logic has to be applied.

Additional Information

• Deletion of history data will be defined in a separate issue
• This does not cover deletion of lists, e.g. EpiData.exposures

[JaquM-HZI]

@MartinWahnschaffe @markusmann-vg Please note that dependencies exist or must be defined for the deletion periods of a field. For example, a non-close contact must be deleted earlier if it has not received a quarantine order than a non-close contact with a quarantine order.

[markusmann-vg]

@JaquM-HZI However, those are rules and is far more than taking a deletion duration and trigger the deletion when it's needed to be applied. It's a whole new story/epic to implement rules with dependencies for deletion.

[JaquM-HZI]

@markusmann-vg as discussed, my comment can be ignored