Perfect mocking mechanism

Problem

Waiter (test_waiter) flakes a lot.

• #373
• #582
• #583
• #584

Proposal

For cases like Waiter, may we need an object to simulate shell responses perfectly for the sake of testing correct behavior of test_waiter.py

We're testing the correct behavior of Waiter

In this case, we want to be sure that in various instances, including simulated ones that are exact to real tmux use cases, waiter behaves as designed.

We want correct mocks

Examine mocking of subprocess responses. In the same way responses mocks requests, this would "tap in" at a low level, while also ensuring our existing tests using real tmux still work without any additional effort.

Maybe also permit real tests

Perhaps also allow e2e tests that use real tmux sessions in the backend too

We don't want to lose benefit of testing against real world scenarios:

1. Existing fuzziness cause by environments, different shells
2. Shell updates, OS updates
3. Tmux updates

Start by reading test_waiter.py and the existing subprocess mocking around Waiter, then review the linked flakiness issues for the real failure cases. Define a low-level mock for shell responses that models real tmux use cases while preserving existing real-tmux tests; done should include deterministic tests for Waiter behavior and a clear approach to optional real-session tests.