Refactor LocationIndexMatch.findNClosest

As per the discussion in #994 (and links therein), we probably need to consider the purpose of LocationIndexMatch.findNClosest, and consequently rename and refactor - at the moment it’s just a direct port from map-matching, and includes some known ‘bugs’ (which are listed as TODOs in the code). It probably won’t be used outside of map-matching, so it’s probably not an urgent fix.

@karussell - maybe you can give some direction for what you’d like to see here?

[kodonnell]

What do you mean here @kodonnell ?

The current behaviour includes features that we may remove in the more general one - specifically:

1. if no results are found in radius, return no results. (Currently, in this case, we’ll return one from within the nine tiles even if it’s outside the radius.)
2. (not) sorting the results - can’t remember if this is required by map-matching or not.

The first will definitely result in some differences in some cases (though as above, pretty rare, and I think it’s probably incorrect in it’s current state).

[karussell]

Closing as duplicate of #1324 (I think, if not please reopen)