multiple occurrences of query params in RoutingResource no longer used

[abyrd]

RoutingResource is pretty complicated because it can create multiple "differential" requests, where each query parameter can be specified more than once. The point was to A) provide a view of isochrone tiles and other analysis tiles as if the documents "already existed" with the server calculating the SPTs on demand and cacheing them, and B) allow comparing multiple such requests at once where only one or two query parameters differed between the two requests to be compared.

Our approach to this kind of work has shifted quite a bit: see Pointsets and Time Surfaces. In order to quickly perform multiple requests and combine them, the server does need to hold on to SPTs. Rather than sending the same routing query parameters over and over e.g. for each isochrone tile, we submit them once and receive a name for the resulting SPT, which is then visible as a "document" in the web API. This reveals the inherently stateful nature of the operation to the user. These names persist, and the server should take care of re-generating the corresponding SPTs from the original request if and when another request comes in for the name but the SPT has been evicted.

Anyway, this means that multiple occurrences of query parameters are no longer used. With the new approach described above, one could just clone the query parameters in the calling client and change one or two fields, then request another named SPT.

Therefore the RoutingResource should be greatly simplified by removing all this code.

[abyrd]

I'd also like to remove the hashcode and equals methods from RoutingRequest, giving it the default identity equality. The only reason for these awkward definitions was to make the LoadingCache work with RoutingRequests as keys. @mattwigway are you using these methods in any way, even implicitly (hashtables etc.) in Analyst cluster?

[JordenVerwer]

Agreed, if we could get rid of that annoying piece of boilerplate, the process of adding new parameters to the API would be simplified significantly.

[abyrd]

The current OTP2 code base does not seem to have this boilerplate, or allow for multiple instances of parameters (List fields). Closing.