This query is still relatively expensive because of its call volume, at least 1 million times per day over the last week. After#20430 the two main remaining call paths are via the Workspace Agents Stats and Metadata APIs.

Disclaimer: Blink helped write tests, identify usage ofdatabase.Workspace fields in downstream functions, identify existing pattern for and write the ticker function, and write comments.

This PR adds caching of the Workspace information on the AgentAPI struct for usage in both child APIs, Notably, for the Metadata API we need to also implement a "fast path" for the section that currently callsGetWorkspaceByAgentID since it's nested within a dbauthz call. We do this by attaching the relevant RBAC object from the Workspace object to the request context, then checking inUpdateWorkspaceAgentMetadata if we have the RBAC object in the contextand if it is correct for authorization purposes. If we do not have the object or it is invalid we fall back to still callingGetWorkspaceByAgentID.

Note that while the workspace agent API struct is constructed at startup and (IIUC) is persistent for the lifetime of the agent/workspace, and makes a call toGetWorkspaceByAgentID during this process, we also need to handle updating of some of the cached fields since the entries within the databasecan change as part of the workspace prebuild process. We could potentially due this via subscribing, via pubsub, to updates about prebuild workspace claims. However, for now this has simply been solved with a 5m ticker to make a call toGetWorkspaceByAgentID.

This should mean we on average callGetWorkspaceByAgentID once every 5 minutes per agent, as opposed to multiple times per-minute per agent for the Stats API and again for the Metadata API. Even in the worst case scenario of a workspace prebuild being claimed at t=N and the next ticker not occurring until t=N+5minutes we should have at most 5 minutes of the current behaviour for each agent in a workspace.

NOTE: there is a remaining issue here; caching of the workspace for stats as it is currently implemented is actually invalid, at least for the ~5 minute period between when a prebuild is claimed and the next update of the ticker the cached Owner information will be incorrect and we'll update some incorrect metrics + skip the entireif !workspace.IsPrebuild() block.

We can either:

1. revert this optimization here and still just always callGetWorkspaceByAgentID for every stats update
2. similar to option 1, but onlyalways callGetWorkspaceByAgentID if the workspace is a prebuild, and the first time itis not we could grab the lock and update the cached workspace information
3. do theright thing for both stats and metadata, and hook into pubsub to get the prebuild claim update ASAP while still avoiding extra calls toGetWorkspaceByAgentID