Scaling input durations internally means we have to also scale values in time windows. The problem is that when using regular timestamps like 1669022846, scaling by a factor of 100 will quickly bring us over the limit for a uint32_t. My first attempt in 6d38cc6 has been to switch Cost and Duration types to uint64_t. It works but is not ideal since it means that we'll store matrices that are basically twice the size in RAM for no benefit (the travel time values themselves fit in a uint32_t).

To avoid the memory overhead my plan is to refactor types further so that:

1. Cost and Duration are only user-facing types used in the json and C API, they stay uint32_t.
2. Everything cost or duration-related internally is computed as a signed int (int64_t gives us plenty of room).
3. Everything cost or duration-related internally is stored as a signed int.

That last point is the one requiring the most changes, but as soon as everything happens in the signed world with enough room, we should be safe from the kind or problem spotted in #831, while not increasing our memory footprint.

I finally went with introducing new "user-facing" cost types UserCost and UserDuration that are uint32_t. Set aside the naming, nothing changed from the API usage (both json and C ).
On top of that, now everything cost/duration-related internally is signed (int64_t), including storage in various objects such as Job, TimeWindow etc.

Just as sketched in #828, a scaling phase applies upon problem definition, then back when formatting solutions.

nothing changed from the API usage (both json and C )

Well, almost: as the last CI build failure shows, users of the C API that provide custom matrices will have to switch from vroom::Matrix<vroom::Duration> to vroom::Matrix<vroom::UserDuration> (same underlying type).

This adds a lot more boilerplate than I first though it would, especially in order to make sure reported results are consistent in output after scaling back to UserCost and UserDuration values. But I think it's worth the trouble since:

• it will open up to further scaling options (required in Better costs modelling at vehicle level #788);
• getting rid of the integer division for values scaling upon each call to cost or duration does seem to improve computing time.

On that last point, here are some values for average instance computing time per benchmark class, using -x 5 on the usual VRPTW benchmarks.