OP#10282: Parse track files off the event loop

[randy-seng]

What this does

Opening an otconfig or adding track files parsed everything on the event loop, so the browser froze for as long as parsing took — on a large project, minutes with no repaint and no way to tell whether anything was happening. LoadTrackFiles.load_async now hands TrackParser.parse_files to asyncio.to_thread and publishes the result back on the event loop, and it opens a progressbar for the duration so the user can see the application is busy. LoadOtconfig gained a matching load_async, and DummyViewModel.load_tracks / _load_otconfig await
it.

Why

Parsing is the expensive part and it is pure — no repository, no observer, no widget — so it is the only part safe to move off the loop.
Everything downstream of it notifies observers that mutate widgets, so _publish stays on the loop. That split is why the use case grew a _parse/_publish pair rather than just wrapping the old __call__ in a thread.

The blocking path could not simply be deleted: PreloadInputFiles loads a --config file at startup, before any loop exists. So both paths stay, and load now raises if it finds a running loop rather than freezing the ui for a caller who picked the wrong one.

ProgressbarBuilder only knew how to decorate a sequence, which cannot track work done on another thread. It gained start(...) -> RunningProgressbar, a handle the caller closes; the default implementation returns NoRunningProgressbar, so command line runs show nothing — their output is already a log.

Notes for the reviewer

Start at OTAnalytics/application/use_cases/load_track_files.py — the load / load_async pair and the _parse / _publish split are the whole change. The docstring on load_async states the invariant the rest depends on.

load_otconfig.py looks like a big diff but is mostly extraction: the old load body became _begin / _publish_before_tracks / _publish_after_tracks / _abort, shared by a sync and an async _apply. The behaviour is unchanged; test_publishes_everything_the_blocking_load_publishes pins that.

Naming: the last commit renamed LoadTrackFiles.__call__ semantics to match LoadOtconfig — load blocks, load_async yields, __call__ delegates to load. load meant opposite things in the two neighbouring use cases before.

The acceptance helper change is the other half of the fix: open_project_otconfig and add_track_via_picker slept a fixed 5s and carried on, which after this change means clicking into an application that has no tracks yet. They now wait for the parsing progressbar to disappear (wait_for_track_loading_to_finish), treating "never appeared within 5s" as "nothing to parse".

Risk and rollout

Anything calling add_tracks_of_files or load_otconfig from inside a running loop now raises RuntimeError instead of silently freezing. That is deliberate and loud, but it is a behaviour change for any call site not updated here — the switch is add_tracks_of_files_async / load_otconfig_async. The desktop and CLI paths still use the blocking ones.

Failure mode to watch for: a progressbar that never closes. close() sits in a finally, so a parser exception still clears it; test_closes_the_progressbar_when_parsing_fails covers that case.

Revert is the four commits — nothing persisted, nothing migrated.

Testing

Still to verify by hand: the acceptance suite (tests/acceptance) — the new wait_for_track_loading_to_finish and the export file polling were
not exercised here, and the 120s timeouts were chosen from local timings rather than measured on CI.

OP#10282

The requested change has been implemented. A review by another person has been done.