Consolidate "seenBy", "performedBy" and "sender" properties to common model

[elsand]

Introduction

There is a need for the serviceOwner to supply information about who did what (perform an activity, send a transmission), which matches that of seen log.

Implementation

We create a common entity for this that includes

• The type of actor associated with this activity/transmission.
  • Enum with the values
    • user
    • serviceOwner
    • userViaServiceOwner
• The natural id for the actor (fnr/dnr/orgnr/system-id etc)
• The resolved name for the actor (Ola Nordmann, Foretak AS)

We need different DTOs for this

• We probably cannot expose PIDs in the enduser-DTOs, but organization numbers are ok
• We instead rewrite PIDs to a hash , generated on the fly for end-user output DTOs

The input validation should:

• Always require actorType
• Require either actorId or actorName, or none of them
  • If actorId is supplied, actorName should be looked up. If this fails, the request should fail.
  • If actorName is supplied actorId should be stored as NULL
  • If neither is supplied:
    • If "actorType" is "serviceOwner", then both id and name is then stored as null. Consumers of the output-DTOs should then assume the "org" of the dialog to be the actorName
    • If "actorType" is "user", then the actorId and resolved name for the dialog party is to be used.

Examples:

ServiceOwner-DTO (output):

{
    "actorType": "user"
    "actorId": "urn:altinn:person:identifier-no:12345678901"
    "actorName": "Ola Nordmann"
}

{
    "actorType": "user"
    "actorId": "urn:altinn:organization:identifier-no:912345678"
    "actorName": "Foretak AS"
}

{
    "actorType": "serviceOwner"
}

ServiceOwner-DTO (input):

{
    "actorType": "user", 
    "actorId": "urn:altinn:person:identifier-no:12345678901"
}

{
    "actorType": "user", 
    "actorId": "urn:altinn:organization:identifier-no:912345679"
}

{
    "actorType": "user", 
    "actorName": "Some custom name"
}

{
    "actorType": "user" // assumed to mean dialog.party
}

Enduser-DTO (person)

{
    "actorType": "endUser",
    "actorName": "Ola Nordmann",
    "actorId": "urn:altinn:person:identifier-ephemeral:0676ad6bdf"
}

Enduser-DTO (organization)

{
    "actorType": "endUser",
    "actorName": "Foretak AS",
    "actorId": "urn:altinn:organization:identifier-no:912345678"
}

Enduser-DTO for seen-log

{
    "actorType": "endUserViaServiceOwner",
    "actorName": "Ola Nordmann",
    "actorId": "urn:altinn:person:identifier-ephemeral:0676ad6bdf"
}

### Tasks
- [ ] Implement as described above
- [ ] Prepare documentation (if relevant - either update working document, or add a new file in `docs`)
- [ ] Add e2e-test (if relevant)

### Threat modelling
- [ ] The identifier hash should be non-stable, ie. not be the same across either application lifetimes (ie. restarts and/or replicas), as this will allow for user identification
- [ ] We are storing PIDs here as well as resolved names. This is presumed to be acceptable as there is a need for secure identification for notority reasons.
- [ ] We are exposing end user names (full names). This is PII.

Acceptance criteria

GIVEN ... WHEN .... THEN ...

GIVEN ... WHEN .... THEN ...

[oskogstad]

@elsand IsCurrentEndUser is missing from the new model, I assume it is still needed?