irregular: fix the local search on infeasible sub-instances

[fontanf]

Problem

With use_local_search=True (off by default), BinPackingWithLeftovers threw linear_programming_minimize_shrinkage(...): wrong LP solution, even for a single 5x5 square in a 10x10 bin, with or without the reduction:

• Through sequential_feasibility, the local search solves Feasibility sub-instances whose bin gets narrower at each iteration. Here, one asked for the 5-wide square in a 4.95-wide bin.
• On that infeasible sub-instance, pack_item had no iteration limit and no progress check. It solved about 23,000 shrinkage LPs until the time limit.
• HiGHS then stopped the last LP on the time limit with no solution, and the empty solution failed the check.

Once that loop stopped, a second bug showed up on data/irregular/tests/multiple_bins.json. When the selected bin had no free space left, assign_item_to_bin placed the new item at the bin centre, inside another item. find_best_edge_separator then threw (violated separation constraint). This also happens on master, but there the time-limit crash came first.

Also found while investigating:

• In linear_programming_minimize_shrinkage, the bin bounds were aabb_scaled * scale_value, scaled twice, so they didn't restrict the items. linear_programming_anchor mixed scaled and original units in the same way.
• Debugging leftovers:
  • initial_solution.txt was written in the working directory at each LP, and infeasible.mps plus exit(1) on an infeasible LP, which would kill a Python process.
  • tmp.json was written, and traces printed to the standard output, before the internal errors.

Fix

• LP not solved to optimality: linear_programming_minimize_shrinkage and linear_programming_anchor check parameters.timer.needs_to_end().
  • If the time limit is reached, they stop and keep the current solution. Before, linear_programming_anchor would have taken an empty solution as the new positions.
  • Otherwise, they throw with the HiGHS model status.
• pack_item gives up, and the local search stops on that sub-instance:
  • if the item fits in no bin of the sub-instance. optimize_item_types_fit only checks the original instance, and the bins of these sub-instances are narrower;
  • if the selected bin has no free space left;
  • in the non-anytime modes only, after OptimizeParameters::not_anytime_local_search_maximum_number_of_iterations_without_improvement (default 100) iterations without the sum of the items' scale factors increasing. In anytime mode, it keeps trying until the time limit.
    • This is what makes an infeasible probe end in the non-anytime modes. The default time limit is infinite, so without it optimize() would never return.
    • On the irregular test instances, 339 of the 340 successful packings needed no such iteration, and the last one needed 81.
    • The parameter is also available in Python and on the command line (--not-anytime-local-search-maximum-number-of-iterations-without-improvement).
• Fix the scaling of the bin bounds in both LPs.
• Remove the debugging leftovers.

Testing

• New test_local_search_bin_packing_with_leftovers: 1 and 4 squares, with and without the reduction. It also checks that no file is written in the working directory.
• New test_local_search_full_bin: multiple_bins.json.
• test_parameters covers the new parameter.
• The local search on every instance of data/irregular/tests no longer throws.
• Checked by hand, not in the unit tests (time limits make them unreliable): 48 runs with short time limits (0.01 s to 1 s), in non-anytime and anytime modes, raised no error. A temporary trace confirmed that LPs were interrupted by the time limit in these runs (16 in non-anytime mode), and that needs_to_end() was then true.
• C++ irregular unit tests: 123 passed. Python tests: 354 passed, 13 skipped, 1 xfailed (test_knapsack_hole, fixed by irregular: keep the holes of item types copied from another instance #627).

Not fixed

On some BinPackingWithLeftovers instances, sequential_feasibility with the local search still runs until the time limit, e.g. three 5x5 and two 4x4 squares in a 20x10 bin. It keeps solving narrower sub-instances after its first solution. This isn't new: on master the same instance also reached the time limit, then threw.