Write user-specified options to TransportNetworkConfig

[ansoncfit]

Users should be able to configure a range of options when creating bundles (then have these options read when a worker builds the corresponding network):

• Pre-build linkages and egress tables for additional street modes via TransportNetworkConfig #862
• Make patterns using parent stations, not stops #114
• transfers.txt should override BOARD_SLACK_SECONDS and OSM walk distance #641
• Save GTFS shapes (Saving shape information in network.dat (r5r) #751)
• Set custom traversal permission labelers (e.g., for Option to disallow walking on street when separate sidewalks present #643)
• Add modifications to "bake in" to the network (added in Cost rasters and LTS from shapefiles #782)
• Override the default SpeedConfig values
• Handle left-hand-drive regions

Update: The paragraphs here are largely superseded by changes in #862. See more recent comments in this issue.
It might be worth the effort to allow some of these options to be set in analysis requests, but it's probably sufficient for at least some of them to be set once at the network level.

But note that "network bundle creation" (on the backend) is not the same as network building (on workers). It's not enough to specify assumptions about streets when uploading OSM -- those assumptions need to be saved somewhere and passed along to the worker that actually builds the network.

One idea is to save a new NetworkBuilderConfig in the bundle manifest json saved to S3. With that approach, we would no longer rely on passing a default TNBuilderConfig in TransportNetwork.fromFiles().

At first glance, a TNBuilderConfig file is read when building a network...

r5/src/main/java/com/conveyal/r5/transit/TransportNetwork.java

Line 209 in bc69f80

builderConfig = loadJson(new File(directory, BUILDER_CONFIG_FILENAME));

But in practice, we don't provide that config file, so R5 reverts to the default in this block...

r5/src/main/java/com/conveyal/r5/transit/TransportNetwork.java

Lines 254 to 256 in bc69f80

	} catch (FileNotFoundException ex) {
	LOG.info("File '{}' is not present. Using default configuration.", file);
	return TNBuilderConfig.defaultConfig();

This current implementation seems subpar, and many of the fields in TNBuilderConfig are for old point-to-point routing instead of analysis.

We could strip out the fallback to a default config, and instead throw an exception if a bundle manifest does not have the config. There's not a backwards compatibility concern, because old workers will continue to have the fallback.

[ansoncfit]

The configuration options at hand could just be in the top level object, rather than in a nested config within the manifest. And actually this flat top-level object would be a networkBuildConfig rather than a manifest. We can safely eliminate the concept of bundle manifests; in storage, these are just [networkId].json without the terms bundle or manifest hardcoded.

[ansoncfit]

Just discussed the idea of allowing network .dat files to be rewritten -- it might be useful for people to be able to save car egress tables, for example, after they have built a network. But there's a lot to consider here, about workers that might already be running etc.

If users want a different config, they can just create a new bundle and select previously used GTFS and OSM.

[ansoncfit]

Initial suggested configuration fields and default values:

• buildGridsForModes: ["WALK"] (Pre-build linkages and egress tables for additional street modes via TransportNetworkConfig #862)
• modifications: [] (Cost rasters and LTS from shapefiles #782)
• saveShapes: false (Saving shape information in network.dat (r5r) #751)
• traversalPermissionLabeler: "us" (Add custom walking traversal permissions via TransportNetworkConfig #943)

[ansoncfit]

Added in #941