Fix incorrect geometry index after advancing

[ahmedre]

After advancing the step, the geometry index sometimes incorrectly refers to an index in the previous RouteStep instead of the current one. This patch recomputes the geometry index when the RouteSteps change.

[ahmedre]

should we be passing the original location here from the caller and using that instead of the snapped location?

[Archdoog]

I also found this to be a struggle to understand as I built the snapping task.

@ianthetechie the core state logic feels like an area of the core where some substantial commenting may help us all down the road. Basically to:

1. Explain what params produce the major state changes like step advancement.
2. To outline cases where unexpected params/vars are used (e.g. the different location vars).

[ianthetechie]

Yeah, agreed.

[ianthetechie]

I probably won't get around to commenting up this before my week ends, but I haven't forgotten about it. Alternately if @ahmedre ends up putting more time into this and identifies missing comments, adding them to this PR would be great too. Otherwise I can tackle improving docs here next week.

[ahmedre]

I have no idea if this is the ideal fix or not, but I saw this case while testing, where, while logging:

               "metadata: " +
                    navigatingState.tripState.remainingSteps.size +
                    " remaining steps, current index; " +
                    navigatingState.tripState.currentStepGeometryIndex +
                    " geometry size " +
                    navigatingState.tripState.remainingSteps.firstOrNull()?.geometry?.size

I saw a case where the geometry index was greater than the geometry size (and, at that point, the current remaining steps size had decreased by 1). Looking at the code, it seems that there's no re-computation of the current step geometry index after the current step changes, causing this to be incorrect.

[ahmedre]

[ianthetechie]

It looks like this doesn't actually solve the problem 😅 I've added some tests.