Return information on paths between origin and destination

[ansoncfit]

In conjunction with the path summaries branch in the ui, this PR allows inspecting paths from the origin to the toLat toLon coordinates in the profile request.

The immediate impetus is debugging some suspect frequency entry generation. The paths in this example involve a ride on route 1, then a transfer to route 2, which runs every 20 minutes, and a 6-8 minute ride to the alighting stop. The numbers immediately following "Path:" are the number of minutes from alighting route 1 to alighting route 2. Note that most iterations imply the maximum waiting time (26 minutes), skewing the travel time distribution to be longer than expected.

[ansoncfit]

For discussion purposes, this PR now has two main changes to record street modes in paths for Taui sites:

• Access: in https://github.com/conveyal/analysis-backend/pull/264/commits/660b6acad3938b2cf61499841c88d2959974fc8c, TravelTimeComputer is modified so that it tracks which street mode is optimal to reach nearby transit stops. This tracking is parallel to the existing functionality of determining the minimum time required to reach nearby transit stops, iterating over requested access modes. PathWriter.recordPathsForTarget() can then use this map to determine which accessMode is used to reach the first stop of each path.
• Egress: in https://github.com/conveyal/analysis-backend/pull/264/commits/7d9dfda6490512b0f1645c2b45695222a9924ec2, an extra step is added to propagation to record each path's egress mode.

[abyrd]

Note that although the base branch was changed from worker-accessibility to dev, this PR still contains all the commits from worker-accessibility. The worker-accessibility branch will probably be revised before being merged, so this PR for saving and returning path info should probably be rebased onto dev (or merged into dev only after worker-accessibility is).

[abyrd]

Looking at d42c906 I realize we're writing only two bytes here, which is breaking the 4-byte alignment of the file. All other values written to the file are a 4-byte integers or strings (or are intended to be 4 bytes -more on that later). If we read this as a typed array in Javascript, we will always be looking at 4-byte windows and interpreting them as numbers. Is this going to be a problem for reading the single byte codes? If we reserve two additional bytes e.g. for access and egress time, making an aligned 4-byte access/egress chunk, will it be straightforward to read those individual bytes out of that array position? @trevorgerhardt I'm not up to speed on the current state of typed arrays in JS, we should check into this.

Also, as I mentioned above these are "intended to be" 4-byte chunks, but in fact we are writing out strings as bytes without specifying the encoding. This can easily break if some machine has a different default encoding and will break the alignment, scrambling the output but probably failing silently. All calls to convert strings to bytes should explicitly specify encoding, and in this case rather than UTF-8 we should probably specify StandardCharsets.US_ASCII which is defined to be "Seven-bit ASCII [...] the Basic Latin block of the Unicode character set", or something like static final Charset ISO_LATIN_1 = StandardCharsets.ISO_8859_1; to confine the output to single bytes.

[trevorgerhardt]

@abyrd using JavaScript DataViews makes it relatively easy to access arbitrary chunks of binary data regardless of the size. From the client side, there's not much trouble there. But I agree we should ensure consistent charsets used to guarantee consistent byte sizes.

[ansoncfit]

Ported to https://github.com/conveyal/r5/pull/634