Keep single execute expression job in the queue

[4e6]

Pull Request Description

close #8965

Changelog:

• update: keep a single ExecuteExpressionJob in the queue
• update: make ExecuteExpressionCommand synchronous to preserve the order of commands
• refactor: separate data structures for Visualization and OneshotExpression to simplify the logic

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[4e6]

Tested manually. A fully async test would introduce a race without being able to synchronize the test with the program execution.

[JaroslavTulach]

I am surprised there can only be at most one oneshotVisualization. That doesn't seem correct to me, but I don't see all the nuances of the implementation.

[JaroslavTulach]

Equality based on class of the job? E.g. only one job may be present regardless of the actual oneShotExpression?

It seems to me that the engine is trying to handle cancellation without understanding what is being cancelled. I think only the IDE can say that a oneShotExpression and its ExecuteExpressionJob shall be cancelled - the engine cannot decide on that.

[JaroslavTulach]

Can there be only one oneshotExpression? That seems suspicious to me.

Especially when (one shot) executions requests are co-leased the oneshotExpressions can accumulate - one the (last) execution finishes, all the oneshotExpressions need to be evaluated and the results delivered to the IDE, I think.

[4e6]

As discussed on the call. One expression per execution context should work in the current use case