Add Lua APIs to check if there are pending transactions, clean up tests

[jbms]

This adds the following Lua APIs:

• scroll.animating(): Returns true if animation is in progress.
• scroll.pending_transactions(): Returns true if there are uncommitted changes.

These APIs allow tests to verify that all changes have been applied.

This also updates the Python tests to run faster and more robustly.

Disable animations by default in the test compositor configuration to avoid unnecessary transaction delays.

Refactor existing integration tests to eliminate time.sleep:

• tests/test_normal_exit.py: Use subprocess.Popen.wait instead of a manual polling loop.
• tests/test_workspace_split_uaf.py: Use the shared compositor (since animations are now disabled by default).
• Other tests: Replace fixed sleeps with wait_for_idle or wait_for_client_map to wait for transactions to settle.

Implement a thorough reset mechanism for the session-scoped scroll_compositor fixture:

• Wrap the session-scoped instance in a function-scoped fixture that calls ScrollInstance.reset() after each test.
• reset() uses kill all to close all views, unplugs extra outputs, reloads the sway configuration to reset defaults (which also recreates the Lua state and discards registered callbacks), and recreates the default workspace 1 to reset its layout modifiers.

Optimize test suite execution speed:

• Add pytest-xdist to the Nix development shell.
• Configure pytest.ini to run tests in parallel with 4 workers by default (-n 4), which is stable under ASan and avoids OOM/thrashing.
• Enable compiler optimizations (-Dbuildtype=debugoptimized for -O2) when building the compositor for tests under ASan.

[dawsers]

No, I don't want people to control the compositor from Lua. The idea of Lua is to write simple scripts, not provide a framework to run tests on the compositor.

Also, I don't want the test suite to become an ends in itself, and we are slowly getting there. More often than not, tests are good, but they quickly become obsolete when a bug is fixed, and regressions are not even easy to find using the old tests because they usually happen because of new code, so in the end you have a huge test suite where finding things is hard, and it only proves lots of old bugs were fixed.

I prefer to document the issues and explain why they happened than to have a myriad of tests that only prove a bug was fixed.

[jbms]

Okay, I removed the Lua apis for animation stepping and querying animation duration. I retained only the apis for checking if animation is progress and if there are pending transactions. I also removed the tests that relied on animation stepping. I explored whether it was possible to implement the animation tests non-intrusively using libfaketime or a similar approach but it seemed to require a lot of complexity so I decided to just remove the animation testing altogether.

[jbms]

A lot of tests for my other changes depend on the test cleanups I added in this PR, so it would be great if you are willing to take this.

I do think it is pretty reasonable to expose some way to query when all previous actions have finished being committed and animations have finished running --- as far as I know there isn't a way to do that currently. If you don't like the lua APIs I would be happy to change it to an IPC mechanism though.

[dawsers]

I want to let you do your thing, but these functions are not something a user can use in a script. Like you discovered earlier, the synchronous part of a script will not execute a queued transaction (and start a new animation) even if a transaction is committed, and that is because it won't receive the client's buffer commit message while in the synchronous part of the script, nor receive the timeout, so queued_transaction->num_waiting is bigger than zero, and transaction_progress() returns early. A user running this:

scroll.command(container, "cycle_size h next")
os.execute("sleep 5")
if scroll.animating() then
  scroll.log("Animating!")
else
  scroll.log("Not animating!")
end

will always get "Not Animating!", because the animation starts after the script ends.

These functions are only useful for testing like you do running the commands just to verify some tests already running in a different process are working, but a user has very little use for these functions, and it may even confuse them because they would expect an animation to be happening after running a command.

What are your thoughts?

[jbms]

It is true that these new lua apis are only useful via ipc. However, #347 makes the lua api available via ipc, which means the lua api becomes a convenient and more flexible and composable way to expose more things via ipc.

I can certainly document them as being intended for ipc use and mostly for testing and debugging and mention the caveats about using them from event callbacks.

[dawsers]

I can certainly document them as being intended for ipc use and mostly for testing and debugging and mention the caveats about using them from event callbacks.

It would be nice to separate these functions from the rest, either by some "developer" mode at compilation time, or at least by adding a new subsection to the manual under LUA that separates these API functions from the rest, and explain a bit why, and what their purpose is.

[jbms]

Okay, I have updated the docs to clearly indicate their purpose and separate them from the other functions.

[dawsers]

Great, thank you!