[SofaConstraint] Issue in GenericConstraintCorrection

[EulalieCoevoet]

In the PR #484, the way of searching the ODESolver in GenericConstraintCorrection changed from
c->get(odesolver, core::objectmodel::BaseContext::SearchRoot);
to
c->get(odesolver, core::objectmodel::BaseContext::Local);
In some of our simulations, the GenericConstraintCorrection is located in the root node. And so no ODE solver can be found, and the user can not set it manually.

In this PR:

• Added data d_ODESolverName, to allow user to specify the ODE solver as it is actually done for the linear solvers
• If no ODE solver found using d_ODESolverName, search in "Local", then in "SearchRoot".
• Some cleaning (including renaming)

---

This PR:

• builds with SUCCESS for all platforms on the CI.
• does not generate new warnings.
• does not generate new unit test failures.
• does not generate new scene test failures.
• does not break API compatibility.
• is more than 1 week old (or has fast-merge label).

Reviewers will merge only if all these checks are true.

[guparan]

Thanks for your PR @EulalieCoevoet :-)
LGTM except that I'd prefer not to add all these using, especially using helper::vector and using std::string because I think they hide too much info.
const vector<string>& solverNames = d_linearSolversName.getValue(); is a good example of this problem. Which vector? Which string?

[EulalieCoevoet]

You know which vector and which string by looking at the using xD
No I understand, it's just that in Defrost, we choose to avoid the blurry of having a code full of path "::".
But if it's not the rule in Sofa, I will change this PR and stop cleaning like that in Sofa.

[damienmarchal]

My 2 cents...
Eulalie is right, there is no 'formal' ambiguity as by just following the vector<> symbol the code editor jump to the 'using sofa::helper'.
Guillaume is right in the fact that allowing using std::vector and using sofa::helper::vector in our code base it will generate a lot of ambiguity.

May I suggest two strategy:

1. 'using sofa::*' as much as you want unless it hides somethings from the stl.
2. 'using sofa::*' even for sofa::helper::vector etc. After all we are in sofa so it makes sense to get rid of as much as of the sofa::prefix for code simplicity. To avoid ambiguities, forbid the employement of using on external type eg no 'using std::vector' or 'using std::string'.

Strategy 2 would produce a very consistent and readable code making it obvious we we are using external object or lib;

EDIT: I forgot to say: 👍 Eulalie for the bugtracking, the fixing, cleaning and PRing

[damienmarchal]

This will depend on which rules we use...but at least don't import std::string and sofa::helper::vector

[guparan]

I agree with your suggestion 2 @damienmarchal. We should add this somewhere in the rules.

[EulalieCoevoet]

Sounds good to me :)
So to be clear I should remove all the using std::*.
And all the using sofa::*, including sofa::helper::vector are okay?

[guparan]

Yup, I guess it only concerns the two lines highlighted by Damien :-)

[damienmarchal]

@fjourdes if you have some time can you drop an eye on the code changes made by Eulalie...before it was fetching the Local only...now Global is a fallback. Could it have bad consequence ?

[damienmarchal]

[ci-build][with-scene-tests]