Let LSFDriver pick num_cpu from the realization object

[berland]

Issue Resolves #8095

Approach Use the Realization object which is pre-populated with the correct cpu count.

• [x] PR title captures the intent of the changes, and is fitting for release notes.
• [x] Added appropriate release note label
• [x] Commit history is consistent and clean, in line with the contribution guidelines.
• [x] Make sure tests pass locally (after every commit!)

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

[xjules]

It makes sense. Just wondering about two things:

• Can num_cpu really change from realization to realization?
• Why are we sending num_cpu explicitly for the OpenPBS driver and not via the same real.num_cpu?

[berland]

• Can it really change from realization to realization?

The previous driver would allow it if the ensemble builder built the realization in that way, but the ensemble builder will not do that currently. Even if the number of CPUs were parametrized in the Eclipse DATA deck (the num_cpu parser in the config will just not work in that case).

• Why are we sending it explicitly for the OpenPBS driver?

I put it into the abstract driver, so it should support the same signature, but the LocalDriver and the OpenPBSDriver will currently ignore it. The OpenPBS driver should be refactored to use the same num_cpu as the LsfDriver, but that will be a kind of breaking change compared to the removed C Torque driver since that is using NUM_NODES and NUM_CPUS_PER_NODE.