web: allow blocking pages on certain progress signals

[dgdavid]

A few weeks ago, in #2909, a small, non-blocking component was introduced to subtly inform users when actions are in progress . This PR introduces its blocking counterpart, allowing Agama pages to subscribe to specific progress signals and block user interactions until those progress events are complete.

The changes in this PR ended up being more complex than initially expected due to an edge case that caused an undesirable flickering effect: the progress indicator would disappear almost simultaneously, or even slightly before, certain proposal queries were invalidated and refetched. This led to a transition from the progress state to an outdated UI, which was not ideal.

To address this, a new hook has been implemented to subscribe to the TanStack Query cache, notifying when specific queries are considered fully refetched after a certain point. This is then used in conjunction with useProposalChanges query invalidation. As a result, it now emits a custom event once proposal-related queries are fully refetched, allowing the Page component to subscribe to this event and unmount the blocking overlay just before React performs the UI redraw.

Please, note that using something like const { isFetching } = useProposalChanges() wasn't suitable for this scenario. For further details, please refer to the code and commit messages.

Additional notes

• Currently, only the software pages (all of them) and the storage proposal page are subscribed to their respective progress scopes. The only pages missing at the moment are the network pages, but since the progress for network is not yet ready, TypeScript raises an error when trying to include these pages in this PR, as it doesn't recognize "network" as a valid scope.

• It would be nice to allow pages to conditionally discard the blocking state based on the number of progress steps. This idea originated with the assumption that one-step progress (like for storage proposals) would be fast, though it might not be for certain users or stacks. It's difficult to predict since other factors such as connection speed, whether the page is remote or localhost, etc can have a significant impact. These factors could be explored further to refine the behavior, if/when time permits.

• Another possibility, which is fully outside the scope of this PR for now because there is no current use case, is to allow pages to subscribe to multiple progress scopes, rather than just one.

[dgdavid]

Maybe I'm misunderstanding something, but using query.state.fetchStatus, query.isStale, or similar properties to directly check here if a query is in a refetching state ended up making things more complex for this scenario IMHO. The hook would need to track multiple statuses transitions (e.g., from stale/invalidated to fetching, and then to success), which increases the complexity.

Instead, working with the dataUpdatedAt timestamp feels simpler and enought for this use case, based on my current understanding.

It would be nice if the library had a built-in way to subscribe to query refetches directly.

[dgdavid]

It would be nice if the library had a built-in way to subscribe to query refetches directly.

I mean, a "decoupled" mechanism other than useQuery for use cases similar we have faced here. . The author argues that useQuery usage should be enough in most cases, but in situations like this, it feels like a more specialized solution would be useful.

[imobachgs]

Just some typos. Otherwise, it LGTM.