greedy_alloc hangs (no progress) on 33-cell input that discrete_alloc solves instantly

[jipclaassens]

While adding a greedy_alloc test to the operator test (GeoDMS-Test t010), the operator turned out to hang on a trivial input.

Symptom

Calling greedy_alloc with exactly the same 11 arguments as the existing (and passing) discrete_alloc test in the Operator config (33 allocatable cells, 3 land-use types, 4 min/max claims, 3 unique partitionings) does not terminate. Log:

DiscrAlloc.Prepare started [[/Allocation/greedy_alloc]]
DiscrAlloc: Prepare created alloc structs for 33 cells, 3 landuse types, 4 (min-max) claims, 3 unique par...
DiscrAlloc.Solve started with suitability container /Allocation/Source/Compacted/SuitabilityMaps
{ DiscrAlloc::Solve
   DiscrAlloc 33: claims for 33 cells: min=25; max=43
   DiscrAllocCells 33: Progress 0/33; 0 calls to UpdateSpl

…and then nothing: the process keeps burning CPU (>15 min for a 33-cell problem) without progressing beyond Progress 0/33. Observed on GeoDMS 20.8.0 (msbuild).

Repro

GeoDMS-Test, Operator/cfg/Operator/Allocation.dms, container greedy_alloc (present but deliberately not referenced from the Spec table — reactivating is adding the row 'Allocation/greedy_alloc/test_attr|greedy_alloc' to Operator/cfg/Operator/results.dms). The container mirrors the allocate_discrete call with greedy_alloc substituted:

greedy_alloc(source/lu_type/name, source/Compacted/ADomain, source/Compacted/SuitabilityMaps,
    source/lu_type/partioning, source/lu_type/PartioningName, source/AtomicRegions,
    source/Compacted/AtomicRegionMap, source/claims_min, source/claims_max,
    source/treshold, source/FeasibleSolution)

If greedy_alloc is not supposed to accept this exact argument combination, a diagnostic error would be preferable over a hang.