Beschränkung erlaubter Sender für einen Zustellpunkt

Es soll möglich sein, die clients zu beschränken, die etwas an einen Zustellpunkt senden können, z.B. um bei hochsensiblen Daten sicherzustellen, dass nur berechtigte Absender Anträge senden können.

Siehe #2449.

Hierzu müssen Zustellpunkte um eine Liste existierenden client IDs erweitert werden.
Da clients gelöscht werden können, ohne dass der Besitzer eines Zustellpunkts dies mitbekommt, kann diese Liste theoretisch ohne Wissen des Besitzers leer werden, wodurch dann jeder an diesen Zustellpunkt senden dürfte.
Deshalb ist es sinnvoll, ein zusätzliches flag senderAccessRestricted einzuführen, welches unabhängig von der Liste gesetzt werden kann.

Destination-API

Das destination Schema muss um die Beschränkungen erweitert werden.
Vorschlag: auf Wurzelebene das optionale Object "senderAccessRestricted" hinzufügen, wenn es fehlt oder senderAccessRestricted.enabled nicht true ist, ist das Senden unbeschränkt.

"senderAccessRestricted" {
    "enabled": true
    "allowedSenders": [
        "06cc6819-3376-40e8-8cdb-080b62daa67e"
    ]
}

• POST /destination-api/v1/destinations - Erweiterung von request und response
• PUT /destination-api/v1/destinations/{destinationId} - Erweiterung von request und response
• PATCH /destination-api/v1/destinations/{destinationId} - Erweiterung von request und response
• GET /destination-api/v1/destinations - Erweiterung der response
• GET /destination-api/v1/destinations/{destinationId} - Erweiterung der response

Zustelldienst

• Erweiterung von Zustellpunkt (DestinationEntity) um optionale Liste erlaubter client IDs und senderAccessRestricted flag
• Implementierung der Änderungen der destination-api
• POST /submission-api/v1/submissions - Prüfung, ob Senden erlaubt ist
• PUT /submission-api/v1/submissions/{submissionId} - Prüfung, ob Senden erlaubt ist
• PUT /submission-api/v1/submissions/{submissionId}/attachments/{attachmentId} - Prüfung, ob Senden erlaubt ist

Bemerkung:

• Sämtliche clients in allowedSenders müssen existieren, andernfalls Fehler 422.
• Die Prüfung kann vermutlich in FCPermissionEvaluator.canCreateSubmission bzw. canModifySubmission umgesetzt werden.
  Gilt dest.senderAccessRestricted == true && !dest.allowedSenders.contains(clientID) führt dies zu Fehler 403/Forbidden.
• Die submission-api muss nicht angepasst werden, da Fehler 403 bereits in allen Operationen enthalten ist.
• Die neue Tabelle destination_allowed_senders kann analog zu client_destinations erstellt werden, d.h. mit on delete cascade triggern.