Add ability to enable/disable the extended kalman filter (EKF)

[kmadsen]

Description

Add ability to toggle the extended kalman filter in navigation native.

• I have added any issue links
• I have added all related labels (bug, feature, new API(s), SEMVER, etc.)
• I have added the appropriate milestone and project boards

Goal

We want to be able to able to toggle the extended kalman filter path.

Implementation

Mapbox location native has a simple boolean check to see if the configuration supports EKF.

This will make it so we can enable/disable EKF at any point in the app lifecycle.

Testing

Please describe the manual tests that you ran to verify your changes

• I have tested locally (including SNAPSHOT upstream dependencies if needed) through testapp/demo app and run all activities to avoid regressions
• I have tested via a test drive, or a simulation/mock location app
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have updated the CHANGELOG including this PR

cc: @Guardiola31337 @mskurydin @LukasPaczos

[codecov-io]

Codecov Report

Merging #2600 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2600   +/-   ##
=========================================
  Coverage     29.04%   29.04%           
  Complexity     1063     1063           
=========================================
  Files           281      281           
  Lines         10831    10831           
  Branches        878      878           
=========================================
  Hits           3146     3146           
  Misses         7342     7342           
  Partials        343      343

[LukasPaczos]

Going forward we should come up with a strategy for mutable options. Should everything exposed in NavigationOptions be mutable? We could possibly be able to reset all available there options and pass them to interested modules with a setter.

[Guardiola31337]

Going forward we should come up with a strategy for mutable options. Should everything exposed in NavigationOptions be mutable? We could possibly be able to reset all available there options and pass them to interested modules with a setter.

Capturing from @SiarheiFedartsou

As I can see from code we can change it any time(even between location updates, but I wouldn't recommend to do it)

It may work for this specific option but not for all of them. This question was brought in the past and we decided to only set it at construction time and maintain it during MapboxNavigation lifetime 👀 how it's implemented in the legacy code

mapbox-navigation-android/libandroid-navigation/src/main/java/com/mapbox/services/android/navigation/v5/navigation/MapboxNavigation.java

Line 1034 in d4aa4cf

mapboxNavigator = new MapboxNavigator(configureNavigator());

mapbox-navigation-android/libandroid-navigation/src/main/java/com/mapbox/services/android/navigation/v5/navigation/MapboxNavigation.java

Lines 1077 to 1085 in d4aa4cf

	private Navigator configureNavigator() {
	Navigator navigator = new Navigator();
	NavigatorConfig navigatorConfig = navigator.getConfig();
	navigatorConfig.setOffRouteThreshold(options.getOffRouteThreshold());
	navigatorConfig.setOffRouteThresholdWhenNearIntersection(options.getOffRouteThresholdWhenNearIntersection());
	navigatorConfig.setIntersectionRadiusForOffRouteDetection(options.getIntersectionRadiusForOffRouteDetection());
	navigator.setConfig(navigatorConfig);
	return navigator;
	}

We should work with @mapbox/navnative and see what options we may want to expose and if they can be updated on the fly.

On a different topic, I'm not a big fan of this solution as MapboxNavigation will keep growing and growing as we expose new options. I believe we should come up with a different approach that don't clutter the entry point of the SDK.

[SiarheiFedartsou]

I think the best solution is to think about setConfig as if it is a part of constructor. I believe at some point we will move it to constructor as well as configureRouter.

[LukasPaczos]

I think the best solution is to think about setConfig as if it is a part of constructor. I believe at some point we will move it to constructor as well as configureRouter.

This would mean that the implementation from this PR is already semi-deprecated and will require breaking changes in the near future to remove the introduced here mutability.

In this case, I think we should refactor this option and pass it only in the NavigationOption when the MapboxNavigation is first created.