fix: synchronous state updates in cacheable-sections and fix type generation

[KaiVandivier]

Follow-up from #1387

Quick tip:

I merged in master to include some recent fixes to avoid unnecessary rerenders from useCacheableSection, which unfortunately clutters up the commit history -- for ease of browsing, this range of commits here includes the relevant test changes. A few small type changes and a bump for @dhis2/cli-app-scripts are not included in these though

The cause:

The failing tests were correctly identifying a change in behavior with React 18: state updates in callbacks were being handled more asynchronously due to batching, which created an unwanted race condition. This section in the linked the batching article had a solution:

What if I don’t want to batch?

Usually, batching is safe, but some code may depend on reading something from the DOM immediately after a state
change. For those use cases, you can use ReactDOM.flushSync() to opt out of batching:

import { flushSync } from 'react-dom'; // Note: react-dom, not react

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React has updated the DOM by now
  flushSync(() => {
    setFlag(f => !f);
  });
  // React has updated the DOM by now
}

We don't expect this to be common.

For some extra context on this hook:

While asynchronous behavior could work for useCacheableSection and the tests could be updated to handle that, the returned values from the hook are intended to give users the chance to make UI changes based on states and transitions. Based on that, I think it makes sense for things to happen sequentially so that consumers have some guarantees for what they can expect:

1. startRecording() is called
2. [If communication with the service worker succeeds, recordingState becomes 'pending' and the promise returned by startRecording resolves -- this is a minor detail]
3. The service worker gets ready to record and cache upcoming network requests, then messages back to the client that it's ready
4. Upon receiving the 'ready' message, these happen synchronously:
   1. recordingState becomes recording
      1. As an example, the Dashboard app uses this cue to turn off progressive loading, so that the whole dashboard is loaded despite some items not being in the viewport
   2. The onStarted callback provided to startRecording() is called
      1. If this is synchronous, recordingState is guaranteed to be 'recording' by this point, so the consumer can more confidently make assumptions about the UI
5. Similar things happen in response to 'done' and 'error' messages from the service worker

[amcgee]

LGTM 🎉

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud