Fix speed issues with LangevinIntegrator by removing unnecessary constraint steps

[jchodera]

@peastman suggests we remove some extra constraint calls to speed up LangevinIntegrator:

cc: openmm/openmm#2532 (comment)

@maxentile : Would there be any issues if we did this (if we're not measuring work)?

[maxentile]

@maxentile : Would there be any issues if we did this (if we're not measuring work)?

I don't think so! To be risk-averse, we erred on the side of including redundant constraint calls by having each R,V,O substep definition be responsible for applying all the constraints it needed, when we were expecting to use this implementation with arbitrary splitting strings. This leads to cases where a substep applies a constraint that was just applied by the previous substep. For any given splitting, we can remove the redundant constraint calls without changing the method's behavior.

[peastman]

You might want to take a look at http://jianliugroup.pku.edu.cn/paper/paper/constraint.pdf. They exhaustively test all possible ways of applying constraints to both the velocity verlet and leapfrog versions of this integrator. For each of them they find there's a few versions that work badly and a lot of versions that work about equally well. The code in the comment linked above corresponds to algorithm 13 in the first column of table 1. That's one of the ones that works reasonably well, but the one they actually recommend is algorithm 9. It would be worth trying that as well: