Revert "fix ios accuracy"

[zbranzov]

Reverts #200
@akera-io
We tested the branch using requestLocation and the implementation before the merge and found that both provide similar location. The difference is that now it always takes 10sec to return a location no matter the timeout.

@akera-io What is your observation after the fix? How do you measure the improvement while using the fix? We don't see any improvement on our side.

[akera-io]

The improvement has nothing to do with the performance, as explained in the comment our need was to get an accurate location for iOS - much like this situation https://stackoverflow.com/questions/14808282/cllocationmanager-not-very-accurate-inital-updates. Using startUpdatingLocation always gives you an 'approximate' location almost instantly regardless of the desired accuracy specified. The new requestLocation API added in iOS 9+ does take into account the desired accuracy and if the location was not active at the time the location is requested it does indeed take more time than the initial implementation but it does provide an accurate location - https://developer.apple.com/documentation/corelocation/cllocationmanager/1620548-requestlocation.

Not sure about the 'always takes 10s' statement, the time out option is still available and it should work - it will reject if no location is acquired but it should not ignore the timeout option.

[zbranzov]

@akera-io Right now using the suggested changes in the repository demo app we are hitting this 10 sec delay
https://stackoverflow.com/questions/39499541/cllocationmanager-requestlocation-takes-about-10-seconds
https://stackoverflow.com/questions/35805712/corelocation-cllocationmanager-requestlocation-takes-10-seconds-to-get-a-callbac
Also in this descriptive article https://fluffy.es/current-location/#requestlocationmighttakelongertoretrievelocationdata is mentioned that it could take 10 sec and our tests confirm it.
We used the current change, waited 10 sec to get location (this is ridiculously long time) and then compared it with the location provided by the previous implementation. Both location seem almost identical with a difference of 1-2 meters. Used iPhone 5s and the demo app.
We don't see any reason to make a breaking change when the process of obtaining location will become slower and will provide the same accurate location.
Isn't it better to start monitoring and use the locations provided for certain period of time to nail down the accurate one? Just use the one with lowest horizontalAccuracy and this should be pretty accurate.

Also, using a timeout less than 10 sec will not return any location because of a timeout error so you cannot get a location faster. Maybe we should keep your change but not making it default and only usable when the user is willing to sacrifice 10 sec in order to get better location (which in our tests it is not better).

[akera-io]

Well, I guess it all depends on the accuracy needed. As it is now get location will give you an inaccurate location on iOS regardless of the desired location specified in options but it will give that almost instantly. If by any chance any app that was using location services was active the location is accurate as well but if location services were not used for a long time we got locations that were even out of the one kilometer range so really not usable for our purpose. I can get around this by starting update location and wait until I get a location with desired accuracy in our app but thought the fact that get location in the default plugin doesn't take into account desired accuracy should be also fixed :)

[zbranzov]

@akera-io The latest details we got are that the response delay of 10 sec is caused by poor or no gps signal. In this case the wi-fi is used to obtain location. The further tests we did without wi-fi and strong gps signal show some accuracy improvement and faster location resolving, so we might leave the current state and not revert your change.