Fix absolute CPU destruction on zoom level change in DEBUG builds

[ClayJay3]

When in debug mode, the webapp's RoverMap component is programmed to check the current map view and pull the current views 10x10 surrounding tile area. If the tiles already exist it doesn't bother downloading the PNGs from google, but it still has to reach out to the basestation API to check if the tiles exist.

If the user zooms in/out too many times within a short period, the API gets flooded with request and the CPU usage on the server jumps to 100% from all the threads making maptile requests. This isn't a problem in production builds since we only cache in debug, but sucks when working with development stuff.

Find a better way to check for a download new map tiles in debug mode. Potential Optimizations:

• Anything level 8 or above is all cached in the database, no need to check if these tiles need downloaded, they are all already downloaded.
• Maybe keep a list of checked positions in the MapTileService, so we only check them once for any given server runtime.
• Maybe leaflet already caches some tiles and we can reference that?
• Only allow one 10x10 zoom level cache to occur at a time?

[bwestley]

I saw this behavior when I was adding waypoints to rovermap. I don't like how adding to the cache is handled. Instead of clients downloading missing tiles and uploading them to the API (multiple clients are downloading/uploading the same tiles simultaneously), I would suggest that the API, in debug mode or with some other flag, download any missing tiles when they are requested. @Byrdman32 What are your thoughts?

[ClayJay3]

I agree. Another possible way would be to move the download functionality from the Rover map component to the MapTileService since it's a singleton. Luckily the component currently reaches out to the API to check if the tile at that x,y,z exists before downloading it so there shouldn't be duplicates in the database, it's just super inefficient.

But moving the check and download to the actual API like you said might be better since it won't have a middleman layer of http requests from .Web to .API.