Sensitivity analysis: add a bus cache to improve input handling perfomance

[sylvlecl]

Please check if the PR fulfills these requirements (please use '[x]' to check the checkboxes, or submit the PR and then click the checkboxes)

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem ? If so, link to this issue using '#XXX' and skip the rest

Quck win for #296

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Perf improvement

What is the current behavior? (You can also link to an open issue here)

Buses may be searched for multiple times in the network.

What is the new behavior (if this is a feature change)?

Buses are searched only once and cached.

On the use case described in the issue, the computation time reduces from ~25s to ~8s

[sylvlecl]

Do not merge yet: I think it will be slightly better to build the full cache once from the start (otherwise we still perform a linear search once for each bus). I will check it.

[sylvlecl]

Do not merge yet: I think it will be slightly better to build the full cache once from the start (otherwise we still perform a linear search once for each bus). I will check it.

So indeed after some tests, building the full cache on first call does not cost much and scales much better (50s for full computation vs 1min30, on large network for sensitivities of buses to all generators).

[flo-dup]

I preferred previous commit in a way, as it avoids computing the full map in the case of having only a few buses for which we want to compute the voltage. But as you said, last one scales up better and we're looking for a quick win here.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

100.0% Coverage
0.0% Duplication