Set ensemble_size dynamically for each batch

[StephanDeHoop]

Issue
Resolves #8848

Approach
Remove the default number of realizations and set it dynamically for each batch when a new ensemble is created. Also, for completeness still setting number of realizations equal to length of the realization list in the config file (in Ert AnalysisConfig and ModelConfig we still use the config dictionary and ConfigKeys.NUM_REALIZATIONS to set the num_realizations field). If we know how many realizations there are, why not set is correctly was my logic. Also cleaned up the hard coded strings by importing the Ert ConfigKeys.

(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 logical -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

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.96%. Comparing base (1315c55) to head (986cce5).
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9012      +/-   ##
==========================================
+ Coverage   90.86%   90.96%   +0.10%     
==========================================
  Files         349      352       +3     
  Lines       21621    21695      +74     
==========================================
+ Hits        19645    19734      +89     
+ Misses       1976     1961      -15     

Flag	Coverage Δ
cli-tests	39.08% <ø> (-0.05%)	⬇️
gui-tests	72.71% <ø> (-0.08%)	⬇️
performance-tests	49.58% <ø> (-0.10%)	⬇️
unit-tests	79.69% <ø> (+0.03%)	⬆️

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.

[verveerpj]

LGTM!

[yngve-sk]

I would rebase the commits so you have the introducing of ConfigKeysErt completely separate from the changing of the default value, the commit with the test fixup now relates to both of these things, it would be nice to have it in sequence and not intermingled. Maybe a bit of a nitpick but I'm not sure about this practice of using these "string enums" in general to access the dicts.

[verveerpj]

I would rebase the commits so you have the introducing of ConfigKeysErt completely separate from the changing of the default value, the commit with the test fixup now relates to both of these things, it would be nice to have it in sequence and not intermingled. Maybe a bit of a nitpick but I'm not sure about this practice of using these "string enums" in general to access the dicts.

That is a very good point. Should we really use these enums? Maybe we can discuss this in the standup.