LBS location cache

[wupeka]

When a device is out of GPS range (e.g. in a garage) it will send LBS location. Traccar will query the external service (Google API) to locate it with every packet, which is inefficient and can be costful.

This PR adds a simple ehcache-based cache of LBS locations.

Closes #3790

[tananaev]

Please provide some information on how it's better than current cache.

[wupeka]

@tananaev Is there any cache? After ~2-3 weeks of just one device sitting in my home (without GPS), sending location updates every 3 minutes, I got a bill for ~$30 for google location services. This is just a quick in-memory cache for devices that are missing GPS signals but are still regularly sending LBS/wifi updates.

[tananaev]

So, you have changed the code without noticing that there is already an in-memory cache available?

[wupeka]

You mean a cache for LBS locations? No, I haven't noticed that.

[tananaev]

Sorry, it's available for geocoding, but I don't think we should use entirely different solution for geolocation.

[wupeka]

I wanted to have a quick working solution before the bill from Google ruins me :)
I have very little experience with Java, so I looked for as out-of-the-box'ish solution to the problem as possible and ehcache seemed to fit perfectly.
The solution used for geocoding might not work here, as there's no garbage collection and no timeouts - we need to eventually get rid of old entries, and LBS data changes over time. An insert-only map would be a possible memory leak here (while it might not be a problem in most real-life cases, it definitely could be a surface attack to DoS the server - by sending a bunch of random LBS/wifi only messages).

[tananaev]

It's an LRU cache.

[wupeka]

OK, now I see it.
That still doesn't solve the 'old data' problem though, unless we'd add a manual 'timeout' field, and that'd complicate it even further. For me, the ehcache solution seems cleaner for this case.

[macano13]

Why you dont use a mozila LBS for free ?