Handle masking of personal identifiers in enduser-API

[elsand]

Introduction

This introduces a masking of all personal identifiers used in the end user models as well as supporting masked versions as input parameters already supporting personal identifiers today

Description

The party and actorId fields in the API both use a urn:altinn:person: namespaced identifier, available in both the parties and dialog search/details APIs. Pids (personal identifiers) are PII and require special consideration as they are sometimes used as authenticators (outside Altinn). In Altinn 2, all outputted PIDs are masked, and partyIds (numerical) are used as the primary key.

Dialogporten will not employ partyIds, as that will constrain the possible users to norwegian persons or businesses. Instead we need a system/register agnostic mapping between a masked and unmasked ID in order to support any kind of identifier later (wallet-ids, EIDAS ids etc).

The masked version of a pid will have to be stable per environment (as with Altinn 2 partyIds). A simple encrypt/decrypt approach will run the risk of exposing pids if the key is lost, or break user experiences (eg. stored search queries/fileter) if the key is rotated.

Implementation

• A new table for mapping between a unmasked id (ie. urn:altinn:person:identifier-no:12018212345) and a masked version of the same identity (eg urn:altinn:person:identifier-no-masked:120182:feaglk34s) should be introduced. The mapping should be one-to-one.
• The masked identifier should be masked on a per-identifier-type basis. For now, only urn:altinn-identifier-no prefixes parties should be handled and replaced with urn:altinn:person:identifier-no-masked:120182:feaglk34s where (1) the first six digits (birth date) is preserved, but augmented with a fully random suffix with enough bits to avoid collisions.
• The table should be populated on-demand/lazily, ie. whenever a valid person identifier is referenced within any of the enduser output DTOS.
• This should replace all use of the "ephemeral" ids employed in transmissions, activities and seenlog
• Endpoints taking unmasked identifiers today should continue to do so, but they should also accept masked versions transparently.
• The service owner API should not be changed at all (no masking performed in any DTO).
• The events generated in dialogporten should also mask PIDs

### Tasks
- [ ] Add table and migration
- [ ] Add population/generation mechanism
- [ ] Add handling of masked pids as input parameters in end-user APIs (map/join to unmasked)
- [ ] Add masking to pids in output DTOs in end-user APIs (replacing "ephemeral" pids)
- [ ] Add masking to events
- [ ] Prepare documentation (if relevant - either update working document, or add a new file in `docs`)
- [ ] Add e2e-test (if relevant)

### Threat modelling
- [x] Does this change introduce any potential security issues? No, this closes a concern about pids being exposed to end users.

[elsand]

Just noting here that this feature is an ongoing discussion with legal/security, which hopefully will be resolved well within the upcoming sprint. Until then, we're blocking this.