Update commit status from external CI services less aggressively

What does this MR do?

Reduces the number of cache updates for external CI services, and other users of ReactiveCaching, from one per HTTP request, to one per refresh interval.

Are there points in the code the reviewer needs to double check?

Other services use the ReactiveCaching concern, particularly the online terminal (for callout to an external Kubernetes cluster). This change shouldn't reduce the reliability of these endpoints, but it will affect the frequency with which we poll the external endpoint for data. Hopefully, this is a good, rather than bad, thing.

Why was this MR needed?

External CI services are pulled in the background for updates, using the ReactiveCaching concern. The intent is twofold:

1. Avoid making requests to external HTTP servers in the unicorn request/response lifecycle
2. Aggregate multiple requests, including across clients, reducing the load placed on the external server

Although the first goal was achieved, the second was not - we would unconditionally enqueue a ReactiveCachingWorker every time the commit status for an external CI service was queried by a client.

When the worker runs, it will re-enqueue itself to run every refresh interval for as long as the cached value is alive (i.e., clients are still reading the value). The first time the value is requested for a particular lifetime, the worker needs to be enqueued manually, but it can be ignored in later invocations.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests added for this feature/bug
• Review
  • Has been reviewed by Backend
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together
• Internationalization required/considered
• End-to-end tests pass (package-and-qa manual pipeline job)

What are the relevant issue numbers?

Closes #46131 (closed)