fix(telegram): parse correctly ChatID and MessageThreadID

[NefixEstrada]

With this commit, the ChatID and MessageThreadID configuration of the Telegram notifier now can be configured either with a string or an integer, without any breaking changes for anyone consuming this library or the end users using it in their configuration files.

Fixes grafana/grafana#69950

Reasoning

The Telegram API specification tells us that ChatID can be an Integer or a String and MessageThreadID must be an integer.

---

In the PR grafana/grafana#63085, Grafana started to interpret correctly numbers and booleans from environment variables when provisioning files. So before the change, the following got evaluated:

ENV="1" -> "1" (string)

And after the change it evaluated as:

ENV="1" -> 1 (integer)

---

With this new change, it is currently impossible to provision Telegram's ChatID or MessageThredID, since they're integers, and get parsed as such, like so:

TELEGRAM_CHAT_ID="-1234" -> -1234

And then grafana (using this library to parse the Telegram configuration), throws the following error:

failure parsing contact points: my-telegram: failed to validate integration "my-telegram" (UID telegram-1) of type "telegram": failed to unmarshal settings: json: cannot unmarshal number into Go struct field Config.chatid of type string

Implementation details

In order to avoid introducing breaking changes, I've opted to duplicate the Config structure, making it private and transforming ChatID and MessageThreadID to the type any. Afterwards, the configuration value gets parsed and transformed back to a string, ensuring both string and int variants work.

Other implementations explored

I've also explored two other options:

1. Rollback the changes introduced at Provisioning: Parse boolean and numeric values from environment variables grafana#63085. I've discarted this option since it was introduced for a reason and would also introduce breaking changes for all the users that now are using that featue.
2. Change the ChatID and MessageThreadID from string to int. I've also discarted this option, since it would introduce breaking changes for all the users that are already configuring Telegram using a string in the provisioning templates.

That's why I've opted for duplicating the struct, which is ugly but gets the work done and, more importantly, doesn't introduce any breaking change.

Let me know what you think! This issue is forcing us to stay at Grafana 9.3, which has some security vulnerabilities and not the latest features.

Thank you,

Néfix Estrada
IsardVDI

[CLAassistant]

All committers have signed the CLA.

[NefixEstrada]

Is there any way you could look into this? @armandgrillet