Maxmind geoip provider to support in process db reload upon mmdb file update

[nezdolik]

Title: Maxmind geoip provider to support in process db reload upon mmdb file update

Description:
Maxmind geoip provider currently does not support in process reload of mmdb files, in case such files have been updated externally. Envoy needs to be restarted to have the latest content from mmdb file. High level approach on how this can be supported in process (assuming low churn of updates, Maxmind publishes new versions on weekly basis):

• Create Filesystem::Watcher object for each mmdb file path and watch for file update events.
• Add boolean flag into provider if any lookup is currently in progress
• Whenever update callback in provider is triggered by Filesystem::Watcher:
  ** Check if there is any lookup in progress. If not, mutex lock the mddb object and reload it with MMDB_open call. If lookup is in progress, wait until is not and do the same logic (as in first part). That means reload callback will need to run on separate thread.
  ** Another option add one boolean flag if specific db needs reload and check it in the beginning of subsequent lookup and reload db if needed.
  There should exist single instance of geoip provider based on current implementation (one provider per one config hash).

[nezdolik]

cc @ravenblackx @alyssawilk

[nezdolik]

Also asked if MMDB_open watches for file update, i don't think it is, but there is always hope: maxmind/libmaxminddb#322

[ravenblackx]

Could you use a mutex-guarded shared_ptr and thereby allow requests to read from the old instance until the new one is loaded, then switch the 'source' shared_ptr? Seems like your first option risks a starvation (if there's always someone reading then the update never gets a chance), and the second assumes there is only one reader thread, which I don't think is the case (unless you mean still doing the mutex lock thing and just having one of the threads take on the role of updater).

I don't know how long the load operation is; blocking worker threads for the duration of a load may also be an issue?

[nezdolik]

I will check how long the load operation takes (also with prod version of database). Thank you for suggestion @ravenblackx

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[nezdolik]

lively ping

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.