update metric settings badges to reflect custom reporting frequency

[nichelle-hall]

Description of the change

This PR updates the badges used in the metric settings pages so that they reflect the custom reporting frequency of a metric if the custom frequency is not undefined.

The default reporting frequency for Civilians Complaints Sustained is annual, but a custom reporting frequency has been added such that it is now reported monthly.

Related issues

Related to #16218

Checklists

Development

This box MUST be checked by the submitter prior to merging:

• Double- and triple-checked that there is no Personally Identifiable Information (PII) being mistakenly added in this pull request

These boxes should be checked by the submitter prior to merging:

• Tests have been written to cover the code changed/added as part of this pull request

Code review

These boxes should be checked by reviewers prior to merging:

• This pull request has a descriptive title and information useful to a reviewer
• This pull request has been moved out of a Draft state, has no "Work In Progress" label, and has assigned reviewers
• Potential security implications or infrastructural changes have been considered, if relevant

[lilidworkin]

@nichelle-hall can you do a search to see if there's anywhere else we need to update the rendering of frequency? I just remembered for instance that the badge also shows up on the Data page. Will your change here take care of that, or do we need to make an additional change for that?

[lilidworkin]

curious what @mxosman and @terryttsai think, but I'm wondering if we should define a property like frequencyToUse here, which is customFrequency if not null else frequency, and then just use this everywhere when rendering. That way, up above we could replace

                    {metrics[systemMetricKey]?.customFrequency
                      ? metrics[
                          systemMetricKey
                        ]?.customFrequency?.toLocaleLowerCase()
                      : metrics[systemMetricKey]?.frequency?.toLowerCase()}

with

{metrics[systemMetricKey]?.frequencyToUse?.toLowerCase()}

[mxosman]

I really like that idea - love how clean it makes rendering the frequency! Let me know if TypeScript gives you any trouble, Nichelle!

[nichelle-hall]

I wanted to leave the default frequency because I wasn't sure if it would be included as part of the design. For example, if the user wanted to see what the default was while scrolling through, or wanted to set every metric back to default. That said I think Humphrey's designs will come soon! I won't let this be blocking for more than a couple days but will finish up the other follow-ups first before doing these changes.

[nichelle-hall]

For example, I wonder if we would want to include the default in the data tab design since we may need to distinguish that the reporting frequency has changed if we want to change the x axis of the charts.

[mxosman]

That's a great call - makes sense why you'd need them separated in the cases you mentioned!

[mxosman]

LGTM! Thank you, Nichelle!

[lilidworkin]

Sounds good, thanks for explaining your reasoning @nichelle-hall !