Add geo node status metrics to usage ping

What does this MR do?

This will add all of the geo node status statistics to the usage ping, under a new key. The new key will be an array with an element for each node that contains all of the metrics that we collect on geo secondaries.

Related to #273133 (closed) Also related to #298781 (closed)

Database Queries

The only added query in this case is GeoNodeStatus.for_active_secondaries. In order to generate a result that returns any rows, I ran this query in staging, where we only have one node. According to our usage data though, the most geo nodes any customer has is 10 at the moment.

Query

SELECT
    "geo_node_statuses".*
FROM
    "geo_node_statuses"
    INNER JOIN "geo_nodes" ON "geo_nodes"."id" = "geo_node_statuses"."geo_node_id"
WHERE
    "geo_nodes"."primary" = FALSE
    AND "geo_nodes"."enabled" = TRUE

Explain Plan depesz

 Nested Loop  (cost=4.76..8.30 rows=1 width=1206) (actual time=0.092..0.093 rows=1 loops=1)
   Buffers: shared hit=8
   ->  Seq Scan on geo_nodes  (cost=0.00..1.02 rows=1 width=4) (actual time=0.007..0.008 rows=1 loops=1)
         Filter: ((NOT "primary") AND enabled)
         Rows Removed by Filter: 1
         Buffers: shared hit=1
   ->  Bitmap Heap Scan on geo_node_statuses  (cost=4.76..6.27 rows=1 width=1206) (actual time=0.082..0.082 rows=1 loops=1)
         Recheck Cond: (geo_node_id = geo_nodes.id)
         Heap Blocks: exact=4
         Buffers: shared hit=7
         ->  Bitmap Index Scan on index_geo_node_statuses_on_geo_node_id  (cost=0.00..4.76 rows=1 width=0) (actual time=0.072..0.072 rows=8 loops=1)
               Index Cond: (geo_node_id = geo_nodes.id)
               Buffers: shared hit=3
 Planning Time: 0.646 ms
 Execution Time: 0.288 ms

Is this query efficient? Not particularly, but given that the largest table we know of for this is 10 rows, and this query will return 9 - I'm just not that worried.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team