Add `agent_users_using_ci_tunnel_monthly` equivalent metric for GitLab.com at the namespace/project/user level

Problem to solve

We have instance+tier+MAU detailed data for Self-Managed agent usage with agent_users_using_ci_tunnel_monthly. At the same time GitLab.com is a single Gitlab instance, thus we don't have the breakdown of data on gitlab.com.

To improve our reporting and planning, we would need namespace/project/user level data on gitlab.com equivalent or richer to agent_users_using_ci_tunnel_monthly.

Proposal

Use the Internal analytics framework to implement gitlab.com only metrics for (in the order of importance):

1. namespace-based MAU metric on overall KAS usage (equivalent to agent_users_using_ci_tunnel_monthly) OR project-based MAU metric on overall KAS usage (more detailed than the above as we can see usage at the project level; namespace-level data can be retrieved by aggregating to the namespace) where the project is the agent configuration project
2. project-based MAU metric on CI usage (a project-based equivalent to k8s_api_proxy_requests_unique_users_via_ci_access_monthly) where the project is the agent configuration project
3. project-based MAU metric on UI usage (a project-based equivalent to k8s_api_proxy_requests_unique_users_via_user_access_monthly) where the project is the agent configuration project
4. project-based MAU metric on PAT usage (a project-based equivalent to k8s_api_proxy_requests_unique_users_via_pat_access) where the project is the agent configuration project

If we should pick from the above for performance reasons project-based MAU metric on overall KAS usage is the most important.

Implementation

kas

kas can collect user ids grouped by agent configuration project in addition to all the same existing aggregated counters: k8s_api_proxy_requests_unique_users_via_ci_access, k8s_api_proxy_requests_unique_users_via_user_access, k8s_api_proxy_requests_unique_users_via_pat_access. It can then send this information to rails as part of existing API calls in the usage_metrics module.

We currently send the following data:

type UsagePingData struct {
	Counters       map[string]int64   `json:"counters,omitempty"`
	UniqueCounters map[string][]int64 `json:"unique_counters,omitempty"`
}

We can do something like this:

type UsagePingData struct {
	Counters                 map[string]int64             `json:"counters,omitempty"`
	UniqueCounters           map[string][]int64           `json:"unique_counters,omitempty"`
	IntGroupedUniqueCounters map[string]map[int64][]int64 `json:"int_grouped_unique_counters,omitempty"`
}

We might want to group by strings in the future, so this one is named int_grouped_unique_counters.

We then add k8s_api_proxy_requests_unique_users_via_ci_access_by_agent_project, k8s_api_proxy_requests_unique_users_via_user_access_by_agent_project, k8s_api_proxy_requests_unique_users_via_pat_access_by_agent_project grouped unique counters and fill them with data.

Rails

Add the new counters above to the expected params and known events.