Names lookup in Register that Notifications can use in keyword replacement

[SandGrainOne]

Description

Notifications have a needs for the first, middle and last name of a person as separate properties. The values will be used in search and replace operations when notification texts contains keyword for those values. Register currently doesn't have a suitable endpoint that provide this, so we need to make changes to Register.

This issue will make changes to the register/api/v1/parties/nameslookup endpoint in Register with a new parameter and optionally include the name of a person as separate properties for first, middle and last name.

Additional Information

There was an analysis of existing endpoints in Register: #589. This concluded that we needed changes in Register and potentially in Altinn 2 (bridge). After a talk with the team responsible for Register we've found a solution isolated to Register.

Tasks

• Expand the Altinn.Platform.Register.Models.PartyName model with properties for FirstName, MiddleName and LastName. Decorate the properties with [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
• Rewrite the Altinn.Register.Clients.PartiesClient.GetOrAddPartyNameToCacheAsync() method to support a more complex entity instead of only a single string. It's a private method so we could consider using a record struct.
• Add a parameter to the Altinn.Register.Controllers.PartiesController.PostPartyNamesLookup() method called splitpersonname. The value should be used to optionally populate first, middle and last name during mapping to the PartyName model. (In a future version of Register the default behavior of the logic is to not retrieve the values from the database unless specifically asked for. This is future proofing.)
• Update the call chain between private methods in the PartiesClient class to support the struct. It should be unnecessary to make any changes to LookupPartyBySSNOrOrgNo().

Acceptance Criterias

• The Register API register/api/v1/parties/nameslookup endpoint returns the person name split across separate properties in addition to the original name property.
• The new properties are null for organizations and excluded during serialization.
• MiddleName is null and excluded during serialization unless the person actually have a middle name.

Post-Implementation Changes

The register/api/v1/parties/nameslookup endpoint has been updated to accept a new query parameter: partyComponentOption. Below are the use cases and expected outcomes for this parameter:

• ?partyComponentOption=person-name: Name components will be populated and returned.
• ?partyComponentOption=none: A "Bad Request" error will be returned.
• ?partyComponentOption=anything-else: A "Bad Request" error will be returned.

[olebhansen]

Checking with Register to get any inputs and/or a go-ahead to do the change and sent a PR.

[olebhansen]

OK to submit PR. Check/validate approach with @Alxandr before starting.

[olebhansen]

Input from refinement: v1 can be 1-by-1 lookups

[SandGrainOne]

Manual testing: Looks fine. Working as expected.