Refactor common context handling pattern

[radeusgd]

• Closes Refactor: improve and use Context.if_enabled for the common Forbidden_Operation check #9080

Important Notes

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,
  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.

[jdunkerley]

Looks good but also looks like it is called virtually every single time with panic=False so feels like that should be the default.

[radeusgd]

Looks good but also looks like it is called virtually every single time with panic=False so feels like that should be the default.

Until we implement something like #5430, it is very easy to 'lose' track of a dataflow error if the result of the operation is not threaded-through further. This is especially likely for side-effecting operations - which Output operations often can be.

Thus, as explained in the doc comment

         A dataflow error may be lost if the result of the action is not used,
        so raising a `Panic` is safer. However, when we know that the result is
        not discarded, the dataflow error is preferred.

I thought that it is better to deliberately keep the panic as a default. Then, switching to dataflow error mode has to be done fully consciously, and I assume the user of the function will only do so if they know it is safe.

If the dataflow error mode were the default, someone may use this function in a place where the result is discarded, causing very confusing behaviour (when the Output context is disabled, nothing would happen but there would be no error either).

[hubertp]

Approving engine changes

[enso-bot]

Radosław Waśko reports a new STANDUP for yesterday (2024-02-19):

Progress: Fixing some unexpectedly failing tests, got the PR merged. Final touches for #9021. It should be finished by 2024-02-19.

Next Day: Next day I will be working on the #9021 task. Ensure tests pass for S3 refactor. Look into next tasks, probably #9022