Fix add subform race condition

[bjosttveit]

Description

The PDF subform test would sometimes fail when filling out the subform data. The problem was that the data element did not exist in the instance data, and so the data model could not be determined to be writable. Right before adding the new subform entry, the test would fill out two fields in the main form, and immediately click the add subform button. This causes a save to happen at the same time as we are adding a subform. When saving, we get updated instance data from the backend, and when adding a subform, we get the data element back which we manually append to our local instance state. In this case we can have a race condition where the backend does not have the new subform data element when processing the save, and so the updated instance data does not contain this. If that response is somehow processed after we add the new subform data element to our local instance state this would get overwritten by the new instance data from the save response. Then when entering the subform, we cannot find the data element.

The solution is to use locking in the same way we do for custom actions and file uploading. This causes us to wait for save before sending the request, and block new saves until we are finished.

I also noticed that the loading state for custom buttons (which are used for exiting subform) was a bit insufficient. It only shows loading while a server action is pending, but just like navigation buttons, we can wait for saving / validation where we should also show a spinner. So I added the useIsProcessing hook to show a loading state while the entire button callback is running. To make this work properly, I removed the promisify wrappers around client actions, which would effectively create a new promise and resolve it after a setTimeout(..., 0), which undermines our ability to await these properly. I am not sure what the reason for this was in the first place as I cannot se any mention of it in the original PR.

Related Issue(s)

• https://digdir.slack.com/archives/C076GU2QHCG/p1739187481797139

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
57.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud