Do not report exceptions on long running Excel reads

[hubertp]

Pull Request Description

This change introduces two modifications:

• ClosedByInterruptException is wrapped in InterruptedException instead of RuntimeException
• when instrumentation encounters InterruptedException it bails early

Having ClosedByInterruptException wrapped in RuntimeException meant that it is being reported as a regular HostException in the engine and to the user. Instead it should be treated specially since we know that it is caused by cancelling a long-running job. Since it is a statically checked exception it has to be declared and the information has to be propagated through various lambda constructs (thanks Java!).

The above change alone meant that an error is not reported for Data.read nodes but any values dependent on it would still report No_Such_Method error when the exception is reported as a value. Hence the early bail out mechanism.
Additional bonus: LS will send PendingInterrupted to GUI that indicates a slightly longer computation that has been interrupted and will be retried.

Closes #11896

Checklist

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

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[hubertp]

Pending some tests but otherwise good to review.

[radeusgd]

I'm wondering if creating some new unchecked variant of InterruptedException wouldn't make things easier?

On the other hand it feels nice that we have a clear indication which methods are more prone to interrupts (although it feels like any method can be interrupted anyway, no?).

Anyway, looks OK.

[hubertp]

I'm wondering if creating some new unchecked variant of InterruptedException wouldn't make things easier?

On the other hand it feels nice that we have a clear indication which methods are more prone to interrupts (although it feels like any method can be interrupted anyway, no?).

It's actually fairly mechanical with a decent IDE. And having checked exceptions is actually pretty beneficial in finding bugs.

[4e6]

We are one step away from inventing monads

[hubertp]

😆