Nav Native API update

[devotaaabel]

This PR Updates the API so that OfflineNavigator#retrieveRouteFor takes in a callback instead of blocking the UI thread. This PR also renames a few things.

This is the current structure of navigation (MapboxNavigation is the only public facing API):

• MapboxNavigation -> MapboxNavigator -> Navigator

To stick with this structure, this is what I am proposing for offline navigation (MapboxOfflineRouter is the only public facing API:

• MapboxOfflineRouter -> OfflineNavigator -> Navigator.

-> in this case denotes a "has a" relationship. If anyone has any opinions about naming, please weigh in.

[danesfeder]

@devotaaabel thanks for running with this and getting the route retrieval off of the UI thread 💯

I only have one question regarding naming - would it make sense to rename MapboxOfflineNavigation to MapboxOfflineRouter or OfflineRouter? The class is really only concerned with fetching a DirectionsRoute offline. The main concern being developers will be confused looking at MapboxOfflineNavigation vs. MapboxNavigation - thinking that MapboxOfflineNavigation will contain another set of route-following APIs that mirror MapboxNavigation.

Only other comment up for discussion is the abstraction work with CallbackAsyncTask. Would it make sense to do the same for the ConfigureRouterTask? It feels like a good opportunity to align that work as they are both working the the OfflineNavigator in the background and both have callbacks.

Although I guess this might be tricky because the CallbackAsyncTask.Callback<R> wants to return a result type and the OnOfflineDataInitialized callback only returns when the data is ready and doesn't return anything.

[Guardiola31337]

@devotaaabel this is looking good, great work!

Just some general comments / questions.

Isn't CallbackAsyncTask.Callback<DirectionsRoute> leaking the underlying implementation to the developer using the SDK? Have we considered exposing callbacks that are very explicit in what they're providing (e.g. OnOfflineDataInitialized, OnOfflineRouteFound, etc.)? Right now, CallbackAsyncTask.Callback<DirectionsRoute> is being passed by the developer using the SDK and CallbackAsyncTask is only used internally (could be package-private) so the dev shouldn't have to care what that is. I'm thinking on something like OnOfflineRouteFound#onOfflineRouteFound(DirectionsRoute directionsRoute) making clear what the callback is doing / giving to you and easier to use.

[devotaaabel]

@danesfeder @Guardiola31337 ready for re-review, you both had conflicting advice for the CallbackAsyncTask, so I just removed it and made the other task non-generic.

[danesfeder]

Thanks for working through the comments / feedback here @devotaaabel ✅

[devotaaabel]

@Guardiola31337 did you want to re-review before I merge?

[Guardiola31337]

Could we add Javadoc to OfflineRouteFoundCallback? Other than that minor comment this looks good to me. Great work @devotaaabel