Fix non-linear shunt compensator section number

[jeandemanged]

Please check if the PR fulfills these requirements

• 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?

No

What kind of change does this PR introduce?

Bugfix

What is the current behavior?

For non-linear shunt compensators, the first section in get_non_linear_shunt_compensator_sections and update_non_linear_shunt_compensator_sections is assumed to be 0 in the dataframe.

This offset is confusing, e.g. for Entsoe's MicroGrid T4 (CGMES_v2.4.15_MicroGridTestConfiguration_T4_Assembled_BB_Complete_v2.zip), we get a max_section_count of 5 and the list of sections is 0...4. Updating section 5 values results in an error.

Note that in update_shunt_compensators setting section_count works OK: 0 means disconnected.

>>> n.get_shunt_compensators(attributes=['name', 'model_type', 'max_section_count'])
                                       name  model_type  max_section_count
id
fbfed7e3-3dec-4829-a286-029e73535685  NL-S1      LINEAR                  1
d771118f-36e9-4115-a128-cc3d9ce3e3da  BE_S1      LINEAR                  1
002b0a40-3957-46db-b84a-30420083558f  BE_S2  NON_LINEAR                  5
>>> n.get_non_linear_shunt_compensator_sections().loc['002b0a40-3957-46db-b84a-30420083558f']
                g         b
section
0        0.000007  0.000346
1        0.000009  0.000519
2        0.000010  0.000658
3        0.000011  0.000727
4        0.000011  0.000762

What is the new behavior (if this is a feature change)?
As per powsybl-core documentation, first section should be 1 // 0 meaning shunt disconnected.

>>> n.get_non_linear_shunt_compensator_sections().loc['002b0a40-3957-46db-b84a-30420083558f']
                g         b
section
1        0.000007  0.000346
2        0.000009  0.000519
3        0.000010  0.000658
4        0.000011  0.000727
5        0.000011  0.000762

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No BUT users relying on previous behavior and who "accommodated" the bug will have surprises.

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[sonarcloud]

Quality Gate passed for 'pypowsybl'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarcloud]

Quality Gate passed for 'pypowsybl'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud