[vg6d_transform] --comp-full-steps issues with 12h comp-step

[brancomat]

(as seen in ARPA-SIMC/arkimaps#117)

test data:
tp_2Iruc.tar.gz

• this works as expected:
  vg6d_transform --comp-stat-proc 1 --comp-frac-valid=0 --comp-step="0 12" tp_2Iruc.grib tp_12h.grib
• this doesn't work (I'd expect a 0-12 cumulated precipitation but there's no output):
  vg6d_transform --comp-stat-proc 1 --comp-frac-valid=0 --comp-step="0 12" --comp-full-steps tp_2Iruc.grib tp_12h_fullsteps.grib

forcing --comp-start="2022-05-18 00" (the reftime of the example data) still doesn't work but forcing --comp-start to a subsequent hours gives the expected output:

vg6d_transform --comp-stat-proc 1 --comp-frac-valid=0 --comp-step="0 12" --comp-start="2022-05-18 01" --comp-full-steps tp_2Iruc.grib tp_12h_fullsteps1.grib
grib_ls tp_12h_fullsteps1.grib
tp_12h_fullsteps1.grib
edition      centre       typeOfLevel  level        dataDate     stepRange    shortName    packingType  gridType     
1            cnmc         surface      0            20220518     1-13         tp           grid_simple  rotated_ll  
1 of 1 messages in tp_12h_fullsteps1.grib

1 of 1 total messages in 1 files

This is curious since in the first example (the one without --comp-full-steps) it seems to be able to compute the 0-12 interval.

(bonus issue: exporting LOG4C_PRIORITY="debug" gives no debug output)

[dcesari]

It did not work when there was only a single "good" step to be copied from input to output without need to compute any difference. I pushed an update that corrects, but this matter of statistical processing on intervals is very complicate and I would like to improve it further.

[dcesari]

In commit 9a7dddf and surroundings a better search algorithm for existing ready intervals has been implemented. It is exact for gridded data, while for sparse data, due to how data are copied from input to output, it may not work perfectly with full steps, however it is netter than before.
Some tests in analysis mode are needed.