Hybrid wait-based approach for test suite

[jamesreprise]

What is the goal of this PR?

We've refactored the test suite to make use of a hybrid wait-based approach for the Studio test suite. That is, when we expect elements of the GUI to change we use ComposeTestRule's waitUntil, blocking until a given condition is satisfied or a timeout is reached. This polls the UI for changes and also recomposes inbetween polls.

We have not entirely refactored out our static delays as some of the events we wait for are outside the scope of elements that fall entirely within Studio's GUI.

What are the changes implemented in this PR?

We make use of ComposeTestRules waitUntil, providing some new functions:

• waitUntilNodeWithTextIsClickable
• waitUntilNodeWithTextExists
• waitUntilAssertionPasses
• waitUntilTrue

Where appropriate, we now use one of the above wait 'family' of functions rather than more rudimentary functions like delayAndRecompose. However, not all of these have been removed.

While this PR has been open, we've migrated from grabl to Factory for our CI! We've included some of those changes here.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.