Combing (Box-)FDDP and (Box-)DDP solvers

[cmastalli]

In this issue, I propose a code simplification for easy maintenance.
I want to draw the attention of @proyan and @nmansard to this issue.

Currently, we have

1. the unconstrained solvers: DDP and FDDP, and
2. the control-bound constrained solvers: Box-DDP and Box-FDDP

In both cases, there is a single different: the feasibility-driven routing for forward pass.
This routine can be easy switch off, without affecting runtime performance, by a configuration parameter to the solver.

Concretely speaking, I propose the following action points:

1. Deprecate DDP and Box-DDP solvers
2. Include a boolean (the configuration parameter) in the FDDP/Box-FDDP constructors to switch from feasibility mode to classical mode.
3. Use as default value of this parameter the feasibility mode, which avoids construction deprecation in FDDP/Box-FDDP solvers

[proyan]

Removing DDP as a solver from our repertoire makes sense. FDDP with feasible initial guess is already DDP.

However, because of historical reasons, I think we need to always keep the DDP as an explicit solver in our list, and inherit from that. DDP is an old and accepted algorithm, and it is comfortable for a new user to start with something familiar

[cmastalli]

However, because of historical reasons, I think we need to always keep the DDP as an explicit solver in our list, and inherit from that. DDP is an old and accepted algorithm, and it is comfortable for a new user to start with something familiar

What I propose is to introduce a flag that makes our FDDP solver behaves as our DDP solver even if the initial guess is infeasible. Something like this

fddp = crocoddyl.SolverFDDP(problem)
ddp = crocoddyl.SolverFDDP(problem, feasibility=False)

(same for box solvers)

I agree that this is not as explicit as writing crocoddyl.SolverDDP, however, the desired behavior is explicitly defined by the user.
Of course, with a proper deprecation protocol, our users will be aware of this approach.
How do you think about this approach?

[jcarpent]

To be honnest, I don't think that calling the solver FDDP will be helpful. Keep DDP naming for universal convention, just deprecate FDDP.

[cmastalli]

To be honnest, I don't think that calling the solver FDDP will be helpful. Keep DDP naming for universal convention, just deprecate FDDP.

I understand your point, but I would prefer to turn on the feasibility as default since it is better option.
If this is the case, then I think DDP should be deprecated.
On the other hand, we have a couple of papers referring to FDDP and Box-FDDP (and there are more citations out there)
Indeed, it is also important for us to keep the FDDP naming, because it is our contribution.