Support reactive power control of a generator on its own terminal

[Hadrien-Godard]

Describe the current behavior

Currently, if a generator reactive power control is defined on its own terminal, the control is discarded, and following line is logged:
ERROR c.p.o.n.i.AbstractLfGenerator | Generator <GEN_NAME> is controlled by an instance of class com.powsybl.iidm.network.impl.GeneratorImpl: not supported

Notice that in IIDM, such a reactive power control is qualified as "remote", although it is local. In CGMES, such a control is not qualified as local or remote (the distinction does not exist), but is converted as a remote one in IIDM.
As "remote" reactive power control is the only way to model reactive power control from a generator in IIDM, we do not consider that this term "remote" prevents us from modeling such a local control in OpenLoadFlow.

Describe the expected behavior

If a generator remote reactive power control is on its own generator terminal, keep it and do not log an error.
We propose to keep it as a new kind of generator control called local reactive power control.

If parameter usereactivelimits is true:
The initial target Q of the generator should be: max( min(Qmax, controlTargetQ), Qmin).
In the reactive power outer loop, we should take this control into account and re-check the values of Qmin and Qmax (which could change as the generator targetP changes) and so recheck the targetQ of the generator.

Else:
The targetQ of the generator is controlTargetQ.

Describe the motivation

The motivation is to model reactive power control that are defined at the generator terminal level.
Those controls ensure that the generator follows a target (as the targetQ field does), but here this target could evolve as the Qmin/Qmax bounds on the reactive power output could evolve during the load flow iterations.

Extra Information

No response

[Hadrien-Godard]

Pending, since we have to deliberate more on the expected behavior.