Allow generating extra recording rules from saturation points

In a couple of places we use hardcoded values to specify the maximum value in saturation points, in other places we specify hardcoded values in one-off recording rules for GitLab.com or a dedicated environment directly. Some examples:

• pvs_cloud_run_container_instances hardcoded max instances
• aws_rds_used_connections, hardcoded, to change in to a recording rule calculation in !6777 (merged)
• aws_rds_disk_space hardcoded disk space
• aws_rds_freeable_memory: hardcoded, to change to a recording rule in !6777 (merged)
• nat_gateway_port_allocation hardcoded for GitLab.com
• pgbouncer_client_connections, hardcoded for GitLab.com
• kube_node_ips, recording rules, for GitLab.com

We should avoid hardcoding values in saturation points, but have them generate recording rules. So we can have more historical information about the saturation point in metrics: Did we resolve an incident by increasing capacity or did we reduce utilisation?

Instead of hardcoding them directly from a recording rule or in the saturation point, we should allow configuring this through gitlab-metrics-config, so we can easily adjust them for different tenants. Ideally, we could define the recording rules from static values passed in through config directly in the Saturation point:

staticRules: {
  rds_max_connections: {
    labels: {
      some: from_config,
      labels: from_config,
    },
    expr: from_config,
  },
},

---

The following discussion from !6777 (merged) should be addressed:

• @cmiskell started a discussion: (+5 comments)

  It is possible to express this as a function of rds_instance_ram_bytes based on the AWS provided formula (what is being done in https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/instrumentor/-/merge_requests/2658 by the caller). Requiring a distinct recording rule raises the requirements on the consumer slightly, and it seems unfortunate we can't be more helpful.

  question: Is there a particular reason you chose this approach vs using clamp_min(rds_instance_ram_bytes/9531392, 5000) in this expression?