alertmanager: Replace typed fields with plain string values

[jkroepke]

Fixes #4029

The Jira API requests different fields value types depends on the custom field type itself.

Ref. https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/#setting-custom-field-data-for-other-field-types, for example:

fields:
    # Components
    components: { name: "Monitoring" }
    # Custom Field TextField
    customfield_10001: "Random text"
    # Custom Field SelectList
    customfield_10002: {"value": "red"}
    # Custom Field MultiSelect
    customfield_10003: [{"value": "red"}, {"value": "blue"}, {"value": "green"}]

While jiralert allowed field values with different types as well, it might be problematic in context of the Alertmanager.

• A new dependency github.com/trivago/tgo was necessary to cast all keys to strings. Ref. https://github.com/prometheus/alertmanager/pull/3590#discussion_r1816521316
• Looking at Prometheus Operator, Kubernetes CRDs doesn't support such flexible types, because type is not allowed inside anyOf. From Kubernetes point of view, all field values must be declared as string and an additional transformation logic is necessary to convert string values to complex values.

I feel that re-implement the logic from jiralert was design flaw while implement the jira notifier at Alertmanager.

WDYT: @simonpasquier @dswarbrick

[dswarbrick]

As I commented in https://github.com/prometheus/alertmanager/pull/3590#discussion_r1817166452, the need for elaborate custom YAML unmarshaling code would be avoided if Alertmanager updated to yaml.v3. I see there was an earlier PR (https://github.com/prometheus/alertmanager/pull/3322) that attempted to update this, but it was not merged because:

We have good reasons not to upgrade to v3, as common and prometheus are stuck with v2.

I see at least one other open PR (#3944) which seems to be encountering a similar scenario.

I found a little more context in this blog post about the release of yaml.v3 by its developer:

To be clear, the Go package always supported decoding into map[string]interface{} (or map[string]anything really), and that continues to work well, but if there is a map inside a map, that second map would be decoded in the most general form for lack of typing information.

This has now changed. When v3 finds a map where all the keys are strings, which is the most common scenario by far, it will automatically decode it into a map[string]interface{} type.