Track users updating milestone for work items

What does this MR do and why?

Related to #367463 (closed).

1. Adds a Redis counter to track unique users updating work item milestone (users_updating_work_item_milestone.)
2. Adds the Redis counter to the existing aggregated metrics.

How to set up and validate locally

To test the redis counter

The added metric (and the updated aggregate metrics) are behind a feature flag that's been defaulted (:track_work_items_activity.)

To see the added event in action, directly increment the counter in the Rails console:

Gitlab::UsageDataCounters::HLLRedisCounter.track_event(:users_updating_work_item_milestone, values: 1)

To test the aggregate metrics

To test the counter's been added to aggregate metrics correctly, follow these steps.

This example considers counts_weekly.aggregated_metrics.users_work_items, one of the updated aggregated metrics.

1. On master branch, execute the following line and note the value.

ServicePing::BuildPayload.new.execute.dig(*"counts_weekly.aggregated_metrics.users_work_items".split('.'))

2. In the rails console, increment the counter users_updating_work_item_milestone.

Since the aggregation happens weekly for the example aggregated metric, time argument should be set to 1.week.ago.

The value here is going to be an author id (we will arbitrarily use 999.)

Gitlab::UsageDataCounters::HLLRedisCounter.track_event(:users_updating_work_item_milestone, values: 999, time: 1.week.ago)

3. Check out the value of the aggregated metric on master and confirm the value didn't change.

ServicePing::BuildPayload.new.execute.dig(*"counts_weekly.aggregated_metrics.users_work_items".split('.'))

4. Check out the value of the aggregated metric on this MR's branch and confirm the value's been updated.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.