metadatagroups with certain security configuration not possible

[floriangantner]

Describe the bug
It's hard to save new created metadatagroups with some security level when the leading metadatagroup field has some authority. The choosen security level is not transferred to the Rest API.

To Reproduce
Steps to reproduce the behavior:

• Tested with Release dspace-cris-2023.02.03 and the dspace-cris-2023_02_x branch with last commit 6af2398 . We also observed it in dspace-cris-2023.01.01

1. Configure some metadata group with some authority controlled value as the leading element
2. Configure security level [2 0] for the leading metadata of the metadatagroup and also for the single members of the metadatagroup (not necessary since 2023.02.02). New metadata should be set not visible by default.
3. Create some new entry. Set it public
4. Create some new entry. Set it non-public (2)
5. Save.

Expected behavior
We expect the security level to be set according to the values choosen on the edit-security-toggler

The PATCH-request to the database does not reflect on changes of the security-level of newly created elements of some metadatagroup and set the wrong security level.

When reloading the submission form the (non-set) security level values of the saved metadatavalues.

Related work
Related to https://github.com/4Science/dspace-angular/blob/dspace-cris-2023_02_x/src/app/shared/form/builder/ds-dynamic-form-ui/ds-dynamic-form-control-container.component.ts and it's addSecurityLevelToMetadata method.

The model.securityLevel contains the choosen value, but the model.value does not contain the security level.