Send large payloads in POST requests

[1ec5]

The Directions API now supports POST requests, which can be useful for certain developers who have a much higher waypoint limit than the default, enough to bump into URL length limits. Currently, this library always sends GET requests to the Directions API and always sends POST requests to the Map Matching API. Correspondingly, RouteOptions.path always includes waypoints, but MatchOptions.path omits the waypoints, instead relying on Directions.calculate(_:completionHandler:) and Directions.dataTask(with:data:completionHandler:errorHandler:) to add the data in the request body.

We should consolidate the logic, so that either code path switches between GET and POST requests based on the payload size. The threshold doesn’t have to be nearly as big as the actual URL length limit, just big enough to know that we’re looking at an atypically large request. But it should ideally be based on the overall URL length, not just the number of waypoints, because of other freeform parameters like waypoint_names. path should probably be split up somehow so we can distinguish what the URL path would be with or without the waypoints.

Alternatively, we could implement logic to retry a GET request as a POST request if the GET request fails due to its size, based on #314. But I think Postel’s law would dictate that we conservatively send a POST request if the payload looks anywhere big enough to run into that kind of limit.

/cc @mapbox/navigation-ios @danpat @danesfeder

[danpat]

Alternatively, we could implement logic to retry a GET request as a POST request if the GET request fails due to its size, based on #314.

As part of testing for the backend work, I uncovered that our CDN (CloudFront) sometimes returns HTTP 413, and sometimes HTTP 414, depending on the actual size of the request. I've noted that upstream (with AWS), but it's a sign that Postel was right, and even trusting error codes isn't good enough.

For reference, the URL length limit is 8192 bytes.