Consider perform name lookups asynchronously upon dialog create/update

[elsand]

Introduction

Name lookups are currently done individually and synchronously upon dialog writes. This should be done asynchronously to avoid any reliance on (mostly uncached) remote API calls upon dialog writes, and in bulk to reduce number of roundtrips to register.

Description

While name lookups are cached, the hit rate for migration/bulk dialog creating scenarios will be fairly low, as they usually span different parties. Preloading the entire FREG and ER into distributed cache is probably unfeasible given the dataset size, and will still incur I/O and performance hits.

By utilizing domain events for name lookups, we can utilize the bulk functionality in the "namelookup" endpoint in the register API, vastly reducing the number of required API calls and network roundtrips. This will likely increase the real-world write performance considerably, as we eliminate any reliance on mostly uncached data (service resource information is cached in memory), leaving us with only having to deal with I/O to the database.

This will though entail that actor names might not be available for consumers, especially for those who rely on events which will attempt to read the dialog very shortly after it being writren to.

Implementation

TBD

Tasks

• Implementation tasks are added here
• Prepare documentation (if relevant - either update working document, or add a new file in docs)
• Add e2e-test (if relevant)

Threat Modelling

• I have considered potential security risks (if risks were found, please list them below)

Acceptance criteria

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

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

[elsand]

Refinement:

• Er dette egentlig et problem? Interceptoren vil sjekke om navnet finnes i databasen allerede, så dette er antagelig bare et "problem" mht migrering av historiske data?
• Må verifsere at faktisk er et problem etter at vi har fått re-seeda YT01 med en større mengde parties som gir en mer realistisk hit rate
• Må verifisere at vi ikke bare kan preloade navnecache i Redis
• Caching enkeltvis vs bulk? Håndering av stampeding herd
• Hvordan kan man faktisk bruke bulk? Notificationhandlers vil jo bare motta en og en domenevent, og må da debounce på en eller annen måte får å faktisk få utnytte bulk-API-et.
• Bør vi la konsumenter selv håndtere at navn er NULL (hvis navneoppslag henger etter?)
• Støtter bulk-API-et partial suksess? (eller vil et feilet oppslag blokkere andre i samme bulk?)
• Må utvide dialogcreated/updated events til å inneholde actor-innslag som skal oppdateres (som da settes direkte uten å gå via dialog-aggregat)