Persist original JSON response

[1ec5]

An application may want to add its own request/response logging functionality. Currently, if it uses the built-in URL request functionality, it has to transform Route objects and so forth into a string-convertible format. We should add the original serialized JSON to the completion handler just in case the application needs it.

/cc @willwhite

[1ec5]

We could consider storing the original JSON response in the RouteResponse class that was made public in #393 and would be documented as part of #391.

Storing the original JSON would incur some additional memory usage, but it would avoid the potentially expensive roundtripping from JSON to Swift model objects back to JSON that the navigation SDK has to perform for MapboxNavigationNative. That roundtripping has also proven fairly brittle, because MapboxNavigationNative is a lot stricter than this library has historically been about the JSON that it accepts.

[1ec5]

Currently, if it uses the built-in URL request functionality, it has to transform Route objects and so forth into a string-convertible format.

This issue was originally written against a version of the library that supported Objective-C and didn’t use Codable, so round-tripping was a laborious, error-prone affair. Migrating to Codable eliminated a large class of errors and made us feel much more confident about relying on round-tripping.

Storing the original JSON would incur some additional memory usage, but it would avoid the potentially expensive roundtripping from JSON to Swift model objects back to JSON that the navigation SDK has to perform for MapboxNavigationNative.

JSON conversions no longer figure as large in performance profiles as they did when we relied on JSONSerialization directly, and the performance problems we initially experienced when investigating Codable have not turned out to be a noticeable problem in practice.

That roundtripping has also proven fairly brittle, because MapboxNavigationNative is a lot stricter than this library has historically been about the JSON that it accepts.

#637 proposes storing each JSON object’s unrecognized keys in a loosely typed property and round-tripping it when encoding back to JSON. That approach effectively solves this problem, because clients such as MapboxNavigationNative only need the JSON to be equivalent in value; any differences in whitespace formatting and key order shouldn’t matter.