reduce cache retry load

[fspmarshall]

Introduces a new exponential backoff type and applies it to non-control-plane caches. The intent of this change is to help us better reduce thundering herd effects in large clusters (10k+ agents).

The new exponential backoff starts off with comparatively sized delays, but escalates much quicker on recurring errors. We also increase the maximum retry for non-control-plane caches from 90s to 256s, though most users will actually experience an increase from 60s to 256s since the switch from 60s to 90s was very recent.

The old standard retry behavior resulted in an approximate sequence of 0s, 12s, 24s, 36s, 48s, 60s for all instances. The new behavior as of this change results in an approximate sequence of 0s, 5s, 10s, 20s, 40s, 80s, 90s for control-plane elements and an approximate sequence of 0s, 16s, 32s, 64s, 128s, 256s for peripheral agents.

---

In addition to the primary behavioral changes described above, this PR also makes two more minor changes. Caches now allow their full max backoff for the init event to show up instead of a fixed one minute (slow init event propagation has been observed as a source of excessive cache re-init errors in high load clusters). The maximum backoff used by the cache is now also configurable like so:

teleport:
  cache:
    enabled: yes
    max_backoff: 12m

While the default value of 256s is probably sufficiently large for most clusters, very large clusters might benefit from bumping this even higher.

[zmb3]

Wouldn't hurt to rerun the GHA tests a few extra times on this, as these types of changes have caused flakiness in the past.