Squash logs

[eqbech]

Issue
Resolves #12921

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.11%. Comparing base (6b3c53a) to head (f6d36f4).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12933      +/-   ##
==========================================
- Coverage   90.22%   90.11%   -0.11%     
==========================================
  Files         445      445              
  Lines       30763    30851      +88     
==========================================
+ Hits        27755    27802      +47     
- Misses       3008     3049      +41     

Flag	Coverage Δ
cli-tests	36.84% <100.00%> (-0.05%)	⬇️
gui-tests	67.35% <100.00%> (-0.15%)	⬇️
performance-and-unit-tests	76.73% <100.00%> (-0.07%)	⬇️
test	46.02% <22.22%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andreas-el]

Only need to rewrite the test test_run_poly_example_with_design_matrix.

    for param in ["a", "b", "c", "category"]:
        assert f"Getting parameter {param} from design matrix" in caplog.text

[berland]

Ert itself does not log anything to Azure, so it feels weird to impose Azure limitations into Ert's codebase.

The plugin typically used for logging to Azure from Ert already has this batching capability, is that not sufficient?

[eqbech]

Ert itself does not log anything to Azure, so it feels weird to impose Azure limitations into Ert's codebase.

The plugin typically used for logging to Azure from Ert already has this batching capability, is that not sufficient?

Guess it depends on if you care where the string gets split

[berland]

Guess it depends on if you care where the string gets split

I think we can live with the random split-points that we currently get from the logging plugin. It is possible to programmatically reassemble the long strings if really needed.

[codspeed-hq]

Merging this PR will not alter performance

✅ 34 untouched benchmarks

---

_{Comparing eqbech:Squash-logs (f6d36f4) with main (e3a1259)}

[berland]

I think it looks good!

There is the question of whether sample_prior would be slower since we now loop twice over all parameters, but it does not look like the looping itself is expensive (and it becomes faster due to less logger.info calls)

[berland]

A release note label is needed. There is one related to logging.