Pre-build linkages and egress tables for additional street modes via TransportNetworkConfig

[abyrd]

This is a user-configurable version of 010970c in #786.

The user can add "buildGridsForModes": ["BICYCLE", "CAR"] to the TransportNetworkConfig to pre-build linkages and distance tables and serialize them in the network. This should alleviate the problem of hundreds of regional workers all building the same distance tables (though not during some scenario applications, which will require additional optimizations).

Currently there is no way to inject TransportNetworkConfig during a bundle upload. We must manually edit the network config JSON file on the backend server (in ~/cache/bundles/networkid.json) and aws s3 cp to overwrite the copy on S3 before the network is built by a single point worker.

[abyrd]

This appears to be working. After creating a bundle on production I edited its scenario JSON cache/bundles/63dcf6f7fdc3560d3366d09f.json to contain "buildGridsForModes":["CAR"] then copied it to s3 with aws s3 cp cache/bundles/63dcf6f7fdc3560d3366d09f.json s3://scenario-editor-prod-bundles/63dcf6f7fdc3560d3366d09f.json.

I then started two single point analyses in different tabs with worker versions v6.8 and v6.8-5-g8a509ae. Worker logs show the v6.8 worker computing only WALK data and returning a result quickly. Worker logs on v6.8-5-g8a509ae show it computing both WALK and CAR linkages and egress tables (very slowly for CAR).

So existing workers are not bothered by the new field, and new workers build data for the requested modes.

New workers log the mode when they make linkages or egress tables:

INFO  c.c.r.s.LinkedPointSet - Linking pointset to street network for mode CAR...
INFO  c.c.r.s.LinkedPointSet - Done. Linked 297k of 297k PointSet points to streets for mode CAR.
INFO  c.c.r.s.EgressCostTable - Computed new stop-to-point tables from 100 of 7k transit stops for mode CAR.

[abyrd]

To explain the larger blocks of code removed/moved: The first 10 lines or so of buildNetworkFromConfig have been factored out into a new method loadNetworkConfig and called from buildNetwork, such that the network config is availble in the outer buildNetwork scope and not just inside buildNetworkFromConfig. It's needed in the outer scope to read the additional modes in proprty buildGridsForModes. network.scenarioId = networkId was already being set in that outer scope, so there was no need to pass the network ID into the buildNetworkFromConfig method. Most of the other changes are just comments that should reduce the amount of digging needed to understand behavior in the event of future optimizations.

[ansoncfit]

Thanks for the changes and updated comments.