RouteResponseParser Error strategy

[Archdoog]

When using tools like createOsrmResponseParser, your API your API may return a standard data structure (e.g. Valhalla's {"code": "InvalidOptions", "message": "Options are invalid.", "routes": []}). We should offer a method to handle error parsing/throwing through the parser.

[ianthetechie]

Good catch! Yes, it only models the happy path and everything else is a parsing error for now. What we should do to fix this is model both the success and error responses. Serde can model this with an enum having two variants which it discriminates on.

I'm thinking we should:

• Create a new enum with the right serde derive macros that can parse to either a RouteResponse or RouteErrorResponse (type name TBD; we need to determine if the error message format here is Valhalla-specific or not)
• Add a new variant to RoutingResponseParseError which indicates that there wasn't a network or parsing error, but that the routing engine itself returned an error.
• In OsrmResponseParser's parse_response method, the first deserialization step will parse to the new enum. If it's an error variant, we bail and return the error. The public API for parse_response doesn't have to change and you still get error handling semantics both in Rust and upstream (ex: Kotlin will throw a useful exception with the full error details from the backend).

I think this isn't even modeled in the OpenAPI stuff you've been looking at from us btw :P It probably should be.

[ianthetechie]

Idea discussed on the call: passing more "internal" error info up the stack.

[ianthetechie]

Related: #313 and #263