Reset last proactive request date before sending request.

[Woildan]

Another fix I have in my codebase that I didn't contribute back until now.

The problem occurs when you have a server that takes more than a second to return a response to a proactive route update request (slow server or slow network).

When the next CoreLocation update is delivered to the route controller, if the pre-conditions are still met in didUpdateLocations, checkForFasterRoute gets called again, the elapsed time is still > to RouteControllerProactiveReroutingInterval, getDirections is called, previous request is cancelled, new one is sent.

As a result, when a proactive request is sent, another one will be sent every second until the server is able to send a response in less than a second.

Reseting the last update date before sending the request avoids re-sending a request before a full RouteControllerProactiveReroutingInterval seconds passes.

[frederoni]

Thank you for your contributions.

We implemented a similar fix in #1986 in particular 346c2c8. It also avoids interrupting a regular reroute and vice versa in both route controllers. Would you mind taking a look at it and let us know if it fixes your problem?

[Woildan]

After a quick look at your code it looks like it should fix my problem.
I'll test properly when I get a moment and let you know, probably on Friday.

[Woildan]

Fix looks good, I'm throwing my branch away.