Introduce actor name entity

[elsand]

Introduction

In order to reduce Postgre disk usage, we want to normalize the actor names into a separate table

Description

Actors carry a lot of duplication, as the name of the actor is resolved immediately and stored in full. A new approach will introduce a "ActorName" entity/table, which is referred to by id from each actor object within a dialog aggregate.

Name resolution should still happen immediately, but instead of storing the result to the actor-entity directly, a lookup for that identifier/name pair is performed, and if it matches, a reference to that existing actor name is stored into the actor object. If no match is found (either the actor is previously unseen, or has changed name), a new entry is stored and referred to by the actor object. This will effectively normalize the name property of the actor entity, while maintaining immutability with regards to name changing etc.

This should not have any effect on DTOs, ie not change the API contract for endusers/serviceowners.

#387 is still relevant, but out of scope for this issue.

Implementation

We need to convert existing actor name entries to the new table, so a migration script must be made that perform this, ie takes the existing actorid/name and adds (if not already existing) a corresponding entry in the new table which is referred.

We cannot remove ActorName (the string) from the entity in this PR, as all database changes must be made backwards compatible with currently running code. A separate issue should be made to clean up this after conversion has been made and the new version of the code fully deployed and deemed stable.

Tasks

Preview Give feedback

1. Add ActorName entity with actorId (orgnr or pid) and name, and add Actor.ActorNameId (nullable)
2. Add migration for new entity + composite index
3. Add migration to convert existing actor entries
4. Update database lookups to join in actor name table
5. Update DTO mappings
6. Add/update tests

Threat modelling

Preview Give feedback

1. Does this change introduce any potential security issues? No

Acceptance criteria

GIVEN an actor is being created/updated with a name that already exists in the new ActorName table
WHEN the system processes the actor's name
THEN the existing actor name entry is reused, and the actor entity is set to reference the existing ActorNameId

GIVEN an actor is being created/updated with a name that does not exist in the new ActorName table
WHEN the system processes the actor's name
THEN a new entry is created in the ActorName table, and the actor entity is set to reference the new ActorNameId

GIVEN existing actor entities still store full names directly
WHEN the migration script is run
THEN each actor's name is converted and matched to an new/existing entry in the new ActorName table, and the Actor entity is updated to reference the corresponding ActorNameId

GIVEN the DTO contract must remain unchanged
WHEN the new design is deployed
THEN public or external APIs continue returning actor names as before, with no contract changes for consumers

GIVEN legacy code running against the database
WHEN the database changes for the new ActorName table are applied
THEN no breaking changes are introduced, and both old and new code can continue to function during the transition