Read default database refresh threshold from Central Config

[anujc25]

What this PR does / why we need it

• Read default database refresh threshold from Central Config

Which issue(s) this PR fixes

Fixes #

Describe testing done for PR

• Run any command first to make sure the inventory database fetch is done recently.
• Now simulate the central configuration update (in production scenarios this can be done with central configuration fetch that currently happens every 24 hours with 30 min TTL)

Add following two keys to the central configuration to simulate the behavior

$ cat ~/.cache/tanzu/plugin_inventory/default/central_config.yaml
cli.core.tanzu_cli_default_inventory_refresh_ttl_seconds: 2
cli.core.tanzu_cli_default_plugin_db_cache_refresh_threshold_seconds: 2

• Run any command again with 2 second interval and notice the database update is triggered. When running command within 2 seconds the database update will not get triggered.

$ date && tz context list
Thu Sep 12 21:09:10 PDT 2024
[i] Refreshing plugin inventory cache for "projects.packages.broadcom.com/tanzu_cli/plugins/plugin-inventory:latest", this will take a few seconds.
  NAME                                      ISACTIVE  TYPE   PROJECT  SPACE
...

$ date && tz context list
Thu Sep 12 21:09:16 PDT 2024
[i] Refreshing plugin inventory cache for "projects.packages.broadcom.com/tanzu_cli/plugins/plugin-inventory:latest", this will take a few seconds.
  NAME                                      ISACTIVE  TYPE   PROJECT  SPACE
...

$ date && tz context list
Thu Sep 12 21:09:17 PDT 2024
  NAME                                      ISACTIVE  TYPE   PROJECT  SPACE

Release note

Read default database refresh threshold from Central Config

Additional information

Special notes for your reviewer

[marckhouzam]

Thanks for this @anujc25. Can you explain what use case this will allow to address?
My concern is that if we are trying to reduce the 24 hours to a shorter time by updating the central config, then it will take 24 hours for this new setting to be read before it will take effect, which defeats the point. But maybe you had something else in mind?

[anujc25]

Thanks for this @anujc25. Can you explain what use case this will allow to address? My concern is that if we are trying to reduce the 24 hours to a shorter time by updating the central config, then it will take 24 hours for this new setting to be read before it will take effect, which defeats the point. But maybe you had something else in mind?

Basically, This will allow us to update the threshold and TTL before any upcoming change which requires CLI to poll frequently in short time window. Once things are settled we can even update the central configuration to increase the time again if needed. So, this will give us more flexibility to plan upcoming changes wrt to central config.

[prkalle]

LGTM. Thanks!

[vuil]

lgtm, thanks