Incorporate SearchSettings in the new debugger

[gnanabite]

As described in https://github.com/emichael/dslabs/pull/20#issuecomment-1039365182, search tests often have settings to prevent some traces from being explored (e.g., by prunes, by declaring links/nodes inactive, by not delivering timers for some nodes, etc.). This change enforces the SearchSettings specified in a search test to help students to debug the search-based liveness tests.

This change is done in 3 parts.

• The VizClient must be given the SearchSettings so that it can give them to the DebuggerWindow. This is done in https://github.com/emichael/dslabs/commit/58d6be91f26826b0adf791111e18cb727946e239.
• The DebuggerWindow must accept the SearchSettings and show the prunes and goals to the left hand side. This is done in https://github.com/emichael/dslabs/commit/333c63c6a1ebd73946c5a4b2d1aa919d25d167af.
• In a SingleNodePanel, actions which are prohibited according to SearchSettings must be impossible to take. Moreover, if the search reaches an end state (goal matched, invariant violated, or prune reached), all actions should be impossible to take. This is done in https://github.com/emichael/dslabs/commit/d451e7269675d62f63e5e96a26f80d3e3d2743f3.

NOTES:

• Commits https://github.com/emichael/dslabs/commit/58d6be91f26826b0adf791111e18cb727946e239 and https://github.com/emichael/dslabs/commit/333c63c6a1ebd73946c5a4b2d1aa919d25d167af remove unused constructors and replace data structures. The commit messages explain why these changes were made, but they're not necessary for incorporating SearchSettings.
• This change doesn't yet add tooltips to explain why the messages cannot be delivered. At the moment, I don't see how to use the SearchSettings to get a string explanation of why a message/timer can't be delivered. But we should eventually add tooltips to explain why some messages/timers aren't deliverable.
• This change doesn't take the dropped network into account.We only dropPendingMessages in two tests in lab 3, so I think it's lower priority compared to this.

TESTS: manually started the debugger from various search test failures and confirmed that the invariant pane and actions behave correctly. I aimed to check the following:

• Goal pane behaves correctly: in ping-pong's search test, I set the search to send 2 commands with a maxDepth of 2; when the search failed, I checked that we could navigate to a state where all workloads finished, that the goal pane on the left shows that All clients' workloads are finished, and that no actions can be taken in the debugger.
• Invariant violation pane behaves correctly: with the same modifications to the pingpong search, I modified the client to not check received pong values. I checked that we could navigate to a state with an invariant violation, that the invariant pane on the left shows that the client did not receive the expected results, and that no actions can be taken in the debugger. I also checked that from the original search test (no depth restriction), if we don't check pong values in the client, the debugger shows the invariant violated and prevents any actions from being taken in the state with an invariant violation.
• Prune pane behaves correctly: from a valid solution to lab 2, I modified the client to never send results to clients. Running part 2 test 17, I checked that if we take a sequence that causes the ViewServer to send a view with viewNum=3, then the debugger shows that the prune was reached and prevents actions from being taken.
• Messages on inactive links are not deliverable: same test as above, server3 is marked inactive by the test, and no messages from server 3 are deliverable.
• Timers on requested nodes are undeliverable: I took a valid solution to lab 3 and modified test 23 to have a maxDepth of 1. I confirmed that timers on servers 1,2,5 were not deliverable.

[emichael]

One other thing that would be nice to have: optionally ignoring all of the restrictions on message/timer delivery via menu option. I think given the current state of things you would just have to call updateState and then pass null to all of the node state panels.

[emichael]

Okay, once all of my review comments are addressed and the menu option to ignore event delivery restrictions is added, I think we're good to go.

About the menu item: this should probably be grouped w/ "View delivered messages" under a "Settings " menu? Perhaps "View delivered messages" should be "Show delivered messages" then?

[gnanabite]

Thanks for reviewing! I think all comments are addressed, and the menu option is added in https://github.com/emichael/dslabs/pull/29/commits/27414f011aa78f5d2b942fbecfa77fee0e20371f.

[emichael]

LGTM!

I just tweaked the text of the new menu item and hid it if there aren't any search settings. After seeing it, I don't love the eye icon, but I also can't think of a better alternative.