update NN to v90.0.0, Maps SDK to v10.4.0-beta.1 and Common SDK to v21.2.0-beta.1

[LukasPaczos]

Description

With this release Nav Native brings 2 breaking changes that this PR tries to integrate:

• Exposed a new road object type of railway crossing. For the railways crossing objects to be provided along the route (without e-horizon), we need a new mapbox-java version that includes added railway crossings to step intersection mapbox-java#1375 as well.
• The native router's refresh API does not mutate the annotations in place anymore but instead returns the raw refresh response, the mutation of annotation happens back on the SDK level now. Also, the native router's API also does not provide the route reference anymore, so to accommodate for this change, the router adapter has to manually find the route that's being refreshed and update the annotations. Tagging @RingerJK for a review here since this touches the changes you recently introduced in Custom Router: delegates invokes from NN if custom Router is provided #5500.

[LukasPaczos]

This PR depends on mapbox/mapbox-java#1376 and a release of mapbox-java, otherwise, we'd see parsing errors when trying to de-serialize the alternative route request parameters coming in from Nav Native.

cc @kmadsen

[LukasPaczos]

This also needs a fix in RouteOptions coordinate encoding (escaping "," when building a URL) to be able to switch to an alternative route and correctly de-serialize the URL provided from Nav Native. I'll cut a PR for that change as well to merge alongside the above one.

[RingerJK]

I don't see in NN release notes why they remove the route param, do you know @LukasPaczos ?

[LukasPaczos]

Nav Native does not swap the annotation on the instance itself, so it doesn't need the route reference anymore. Refs https://github.com/mapbox/mapbox-navigation-native/pull/5420#discussion_r822651362.

[LukasPaczos]

mapbox/mapbox-java#1377 adds handling for the unintentional encoding that NN introduced in the coordinates element on the Directions API URL path.

[LukasPaczos]

This is ready for a final review.

[Guardiola31337]

LICENSE script is failing along with an error in unit-tests-core 👀

e: /root/code/libnavigation-core/src/test/java/com/******/navigation/core/reroute/MapboxRerouteControllerTest.kt: (374, 51): Type mismatch: inferred type is Int? but Double? was expected

FAILURE: Build failed with an exception.

[RingerJK]

🚢

[LukasPaczos]

Turns out that Nav Native unintentionally bumped the Kotlin compiler version to 1.6.10 which is incompatible with metalava tooling. I tried quickly upgrading the metalava version but failed to compile that project from scratch, and couldn't find any other workaround that would help us here short term.

The metalava currently flags the incompatibility:

e: /root/.gradle/caches/transforms-3/b1af0b52d0bcd52c1857e87f685e09d1/transformed/******-navigation-native-90.0.0-api.jar!/META-INF/******-navigation-native_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.0.

but also fails to generate the diffs correctly, for example generates public API description as:

  public static final class DistanceFormatterOptions.Builder {
    ctor public DistanceFormatterOptions.Builder(android.content.Context applicationContext);
    method public com.mapbox.navigation.base.formatter.DistanceFormatterOptions build();
    method public error.NonExistentClass! locale(java.util.Locale locale);
    method public error.NonExistentClass! roundingIncrement(@com.mapbox.navigation.base.formatter.Rounding.Increment int roundingIncrement);
    method public error.NonExistentClass! unitType(com.mapbox.navigation.base.formatter.UnitType? unitType);
  }

with random error.NonExistentClass!. I can only guess this is caused by some incompatibilities in the Kotlin compiler which makes the old version of metalava fail to pickup these classes.

The project seems to be running okay in debug and release variants, even though some helper Kotlin classes from Nav Native were compiled Kotlin 1.6.10, but this is just with my limited testing.

In think the safest approach at this point is to wait for Nav Native to revert the Kotlin compiler bump in the upcoming release, and merge this PR only then.

After that, we can start looking into building an upgrade strategy for Kotlin 1.6.

cc @mskurydin

[LukasPaczos]

Updated to NN v90.0.1 which reverts back to Kotlin compiler version 1.5.31.