Replace Cumulative implementation by state-of-the-art implementation of TimeTabling and OverloadChecking

[ArthurGodet]

Also fixes #1114

[ArthurGodet]

I had problems with git rebase, so, in order to keep a clean git history, we need to squash this PR whenever it is accepted/merged

[ArthurGodet]

Important to note : the failing tests do not rely on the cumulative constraint

[cprudhom]

Here are some results of the new Cumulative (new) in comparison to the current version (base) on instances from the last 6 MiniZinc challenges declaring cumulative constraints.

With LCG off

The two instances that are faster with base than with new are :

• gfd-schedule2_n200f5d50m40k6_10124 : 95s vs 100s
• model4_opt_test03 : 106s vs 154s

The difference comes from the usage of the OverloadChecking algorithm which never helps on these instances.

With LCG on

The two instances where base-lcg is faster than new-lcg are:

• mrcpsp_j30_29_3 : 22s vs 57s
• mrcpsp_j30_54_2 : 12s vs 23s

I still need to understand the differences but as a recall, base-lcg time-based decomposes the cumulative constraint.

[ArthurGodet]

I confirm that base-lcg is based on decomposition for the cumulative. I wonder if the two instances where base-lcg does better are on a short horizon ? That might explain the performance difference.

[cprudhom]

Actually, in the benchmarks, there are 5 instances of mrcpsp_j30, with different results.

Instance	Opt	base-lcg	new-lcg
mrcpsp_j30_25_5	min	27 - 3s - 995n - P	27 - 1s - 2470n - P
mrcpsp_j30_29_3	min	32 - 22s - 24110n - U	32 - 57s - 166551n - U
mrcpsp_j30_33_5	min	48 - 52s - 7150n - P	48 - 5s - 9829n - P
mrcpsp_j30_41_8	min	30 - 42s - 5822n - P	30 - 4s - 7984n - P
mrcpsp_j30_54_2	min	28 - 12s - 9537n - U	28 - 23s - 75877n - P

Edit 1 : I added the number of nodes (XXXn) and the termination (P for proven, U for unproven).
Now, it seems that base-lcg is able to find solutions exploring fewer nodes, but since the decomposition can be big, it also wastes time propagating (see for instance, mrcpsp_j30_25_5 or mrcpsp_j30_33_5).
This, also, mitigates mrcpsp_j30_54_2 because base-lcg is not able to prove the bound, unlike new-lcg.

We can conclude that the decomposition provides better explanations (probably, thanks to additional variables introduced by the decomposition) - which is, as far as I known, not surprising.
On the other hand, the global version of cumulative provides better propagation performances but suffer from weaker explanations.

Question is: can we live with that?

My opinion

Yes, we can

[cprudhom]

Can we consider this PR as ready to be merged ?

[ArthurGodet]

I didn't see your edits. So it seems that mrcpsp_j30_29_3 is the only instance that is better treated by base_lcg, and since the best found solution is not proven to be optimal, I'd say that it is not that important (especially compared to the better results we get wih new_lcg for the other instances). I agree that the explanations of new_lcg seem weaker, but my first impression would be that it is not surprising (even if I can't really explain why).

For me, even if it can still be improved (especially by better detecting when to apply the OverloadChecking or not, to improve performance), I consider that the PR can be merged. Don't forget to squash and merge the PR as the git history of the branch is awful.