Map camera and puck lag behind current user location

Nobody has claimed this yet.

The map camera and user puck current lag 1 second behind the actual user location because both elements are animated. To match discerning users’ expectations, the camera and puck should align with reality as closely as possible, without affecting the timing of non-animated components that also depend on user location updates.

## Problem

Users expect the camera and puck to animate smoothly to every new position. To optimize for smoothness, each animation is set to run for the same duration as the typical interval between location updates from Core Location, which is 1 second (except in some CarPlay environments). If the map view code were to animate to each raw location as it comes in from Core Location, without any prediction heuristic, it would lag up to 1 second behind the stream of location updates in a seesaw pattern, thus continually lagging behind the user’s actual location by a constant 1 second.

## Previous approaches

Originally, RouteController positioned the camera and puck by dead-reckoning a location 1 second ahead of the current location in the direction of motion (course). The dead-reckoning behavior led to swinging and other noticeable course correction due to noisy GPS updates or unexpected turns. #629 tracks removing dead-reckoning from LegacyRouteController for this reason.

The ability to more reliably map-match to the road was the main reason for adopting MapboxNavigationNative in #1510, but the SDK has always asked the navigator for the location at the last raw location’s timestamp, rather than asking it to project ahead by a second.

#2560 proposed to unconditionally advance the SDK’s location by a second for all purposes. However, that change would affect both animated components, such as the map, as well as non-animated components, such as tunnel-induced style switching, maneuver instructions, and arrival detection. In fact, application code has access to the same location data as the SDK; any business logic or UI timed to coincide with specific maneuvers or remaining distances may wind up with inaccurate timing.

In https://github.com/mapbox/mapbox-navigation-ios/pull/2560#discussion_r480298281, I suggested decoupling the map’s view of the current location from the RouteController’s view of the current location. However, that would depend on a mechanism that is being removed for #2583. Even so, we’ll need to rely on the some navigator functionality for projecting the user’s location without affecting the rest of route tracking.

## Next steps

For v1.0.0, RouteController will report the current location without reporting a projected location. For a future version, we’re looking forward to functionality in MapboxNavigationNative that would enable projecting the camera and puck forward without projecting the rest of the SDK forward.

/cc @mapbox/mobile-navigation-team @mapbox/navnative

Start with RouteController and the MapboxNavigationNative projection functionality described in the issue, then review the constraints discussed in #2560 and #2583. Done means the camera and puck can project forward without changing the location used by non-animated components, but the issue names no implementation entry point or test.

Written by the indexing model from the issue text.