More caching abilities

[johnd0e]

cache-details-on-map is very limited, as it shows only portals for which we have full details. And it completely wipes portals on timeout.

1. It would be great to cache placeholder portals too.

2. I think we should keep base info (lat/lng/name), as it rarely changes.

3. Permanent cache

   • in browser storage: https://github.com/isnot/iitc-plugin-cache-local/
   • in db: https://github.com/iitc-project/ingress-intel-total-conversion/issues/1149#issuecomment-276983389
   • external online caching services is possible too, see @Ingressportalbot.

4. Possibility to limit displayed portals to current view area (to save resources)

   • But current view can contain a huge amount of portals, with their markers overlapping. We should consider #129.

[johnd0e]

There are more that one side in the issue:

• To cache portal data itself, at least latlng and title are more or less permanent. It make sense to implement this (session caching) in core, as slightly more data should not harm, as such data are rather compact. E.g. it can be used to populate placeholders title. And provide basis for further expansion by 3rd-party plugins.
• By default all data should be kept in memory, but long-term cache can be implemented by plugins. Such plugin could pre-populate cache in memory with previously stored data. We already have some plugins that fit the scheme, e.g. Bookmarks, Uniques, Keys. But some (imaginary) plugin could store even all seen portals, as long as it keeps reasonable amount of data in memory, and provides some ways of cutting excessive data (e.g. limit to some defined area) .
• And last: definitely we should not display all cached portals on map by default. But plugins may have control on it, e.g. adding as separate layers.

[Artoria2e5]

A lot of the core caches are not referencable from outside the local scope; that needs to change for a plugin to read values from (to put into long-term cache) and inject values to it (from long-term cache).