Make the run dialogue snappier by tuning batching interval

[berland]

The batching interval of 2 seconds is legacy from the time when Ert was a mixture of Python and C, and a lot of threading issues attached. The underlying message structure and message processing infrastructure now handles a lot more messages, and the GUI can thus appear more responsive to the incoming messages from compute nodes.

Issue
Resolves #9491

Approach
Short description of the approach

(Screenshot of new behavior in GUI if applicable)

• PR title captures the intent of the changes, and is fitting for release notes.
• Added appropriate release note label
• Commit history is consistent and clean, in line with the contribution guidelines.
• Make sure unit tests pass locally after every commit (git rebase -i main --exec 'pytest tests/ert/unit_tests -n auto --hypothesis-profile=fast -m "not integration_test"')

When applicable

• When there are user facing changes: Updated documentation
• New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
• Large PR: Prepare changes in small commits for more convenient review
• Bug fix: Add regression test for the bug
• Bug fix: Create Backport PR to latest release

[codspeed-hq]

CodSpeed Performance Report

Merging #9824 will not alter performance

_{Comparing berland:snappy_run_dialog (d77fafb) with main (6a978df)}

Summary

✅ 24 untouched benchmarks

[xjules]

I thought about this, but the issue arises when having max running more than 200. Have you tried big poly with this?

[berland]

I will try with bigpoly, but which issue or negative impact would you look for?

[xjules]

Performance wise. That is whether it makes gui more or less responsive, since this gives more work to ee.

[berland]

When you flood the evaluator with messages (as in bigpoly), the parameter _max_batch_size will determine the behaviour (as far as I read the code), not the batching interval.

[xjules]

🚀