Release the GVL during routing model setup

[erickreutz]

RoutingModel#close_model and #read_assignment_from_routes can spend significant time in native OR-Tools code, but unlike the existing solve wrappers, they currently hold Ruby's GVL for the entire call. This adds callback-aware wrappers that release the GVL during those operations when the routing model uses only native callbacks.

The safety boundary matches the solve path: models with Ruby transit callbacks retain the GVL, while native vector and matrix callbacks allow other Ruby threads to run. Route arrays are converted to owned C++ values before the GVL is released, and returned assignments are wrapped after Ruby execution resumes. The raw callback, solve, close, and restoration entry points are private so callers cannot bypass the callback gate.

The coverage exercises Ruby thread progress during both native calls, callback gating and exceptions, result parity, route conversion ownership, overlapping reads on separate models, and assignment lifetime. Existing routing results and callback behavior are unchanged.

[ankane]

Hi @erickreutz, thanks for the PR. Merged a version of this for read_assignment_from_routes in the commit above, as a comment in the OR-Tools source code indicates "this may take considerable amount of time". Can you share how long close_model is taking?

[erickreutz]

Thanks for merging that! We checked the last 24 hours in production. Across 10,665 close_model calls, median was 3 ms, p95 7 ms, p99 27 ms, and max 204 ms. Only three hit 100 ms.

The long stalls were in read_assignment_from_routes. One took 78.8 seconds, while close_model on that same model took 5 ms. So we’re not seeing the same issue with close_model.

[ankane]

Thanks for checking. Will hold off on updating close_model for now.