feat(sender): add Plivo as a SMS and voice alert-notification provider

[sarveshpatil-plivo]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Adds Plivo as a notification provider with two channels, so nightingale can deliver alerts over SMS and voice.

• plivo-sms sends the rendered alert content as a text message through the Plivo Messages API.
• plivo-voice places an outbound call through the Plivo Calls API using a configured Answer URL.

Following the review on #3271, the config is a dedicated typed PlivoRequestConfig (like PagerDutyRequestConfig) rather than the generic HTTP request config. The stored config holds only user-specific values, which are the Auth ID, Auth Token, source number, and for voice the Answer URL. The endpoint, method, and request body are built in code. Authentication uses Plivo HTTP Basic auth built from the Auth ID and Auth Token.

The two channels are registered in alert/sender/provider/init.go, and default templates in both Chinese and English are seeded in models/message_tpl.go.

Which issue(s) this PR fixes:

Fixes #3271

Companion frontend PR:

The channel configuration form is in n9e/fe#2212.

Special notes for your reviewer:

The provider package builds, passes go vet, and the existing provider tests pass.

End-to-end test through the product: I verified both channels through Nightingale's real notification pipeline, not just the raw Plivo API. Each alert event was routed through a notification rule bound to the Plivo channel, and the send result was recorded in the console. Note that the alert event was injected through the event API rather than fired from a metric alert rule, because the test instance has no metrics datasource; everything downstream (notify-rule matching, channel send, notification record) is the real product path.

Channel config form, SMS:

Channel config form, Voice (Answer URL and Answer Method appear only for voice):

plivo-sms, event routed through the notification rule:

plivo-sms, notification record with status success (Plivo returned 202, message queued):

plivo-voice, notification record with status success (Plivo returned 201, call queued):

Received SMS delivered (Plivo console message insights, status Delivered):

Voice call answered (Plivo console call insights):

Failure case with a wrong Auth Token, the Plivo 401 is surfaced in the notification record rather than swallowed:

Implementation notes:

• Numbers are normalized by stripping a leading +, so an operator may enter either +14155551234 or 14155551234. Building the body in code also avoids the HTML escaping that the generic template renderer would apply to +.
• The voice Answer Method defaults to POST, matching Plivo's default, and is configurable for Answer URLs that are served over GET.

[710leo]

Thanks for the follow-up on #3271 — the backend part looks reasonable, especially moving to a dedicated PlivoRequestConfig instead of the generic HTTP config.

Before we can merge this, three things are still missing:

1. The frontend PR

A new notification channel isn't usable until the config form exists in the console. Since plivo_request_config is a new typed config (not the generic HTTP one), the UI can't render it automatically. Please open a companion PR against n9e/fe, mirroring what PagerDuty does:

• src/pages/notificationChannels/types.ts — add PlivoRequestConfig and extend the request_type union
• src/pages/notificationChannels/constants.ts — add the plivo-sms / plivo-voice entries (default config + logo under /image/logos/)
• src/pages/notificationChannels/pages/Form/Plivo.tsx + wire it into pages/Form/index.tsx (see Pagerduty.tsx as the reference)
• locale entries for all languages under src/pages/notificationChannels/locale/ (en_US, zh_CN, zh_HK, ja_JP, ru_RU)

Please link the two PRs to each other so they can be reviewed and merged together.

2. User-facing documentation

A short usage guide for operators: where to get the Auth ID / Auth Token / source number from the Plivo console, what the Answer URL is and how to host one for plivo-voice, the phone-number format that is accepted, and how to bind the channel to a notification rule. Also worth calling out any Plivo-side prerequisites (number provisioning, destination-country permissions, trial-account whitelisting), since those are the usual reasons a first send fails.

3. An end-to-end test report from within Nightingale

The screenshots you attached show delivery from the Plivo console, which proves the API call works, but not that the channel works through the product. Could you add a report covering the full path:

• creating the channel on the notification-channel page (screenshot of the filled form)
• binding it to a notification rule with a real alert rule
• triggering an actual alert event and showing the received SMS / answered call
• the notification record in the console (notification history / send result), showing success

Both plivo-sms and plivo-voice, and ideally one failure case (wrong Auth Token or bad number) to show the error is surfaced sensibly rather than swallowed.

Once those are in place we'll do another round of review. Thanks for the contribution!

[sarveshpatil-plivo]

@710leo Apologies for the delay in getting the frontend PR up. It's now open at n9e/fe#2212, and I've updated this PR to address your review.

Short summary of what's in place:

• Backend keeps the dedicated PlivoRequestConfig, with the URL, method and body built in code, and both English and Chinese default templates seeded.
• The frontend PR adds the config form for both channels, PlivoRequestConfig plus the plivo request type in types.ts, the constants.ts entries and logo, and locale strings for all five languages.
• I added an end-to-end test through the product in the notes above, covering the filled config form, the notification rule binding, the notification record showing success, and a wrong-token failure case, for both plivo-sms and plivo-voice.
• A short operator usage guide is ready as well, and I can put it wherever suits the docs site.

Happy to adjust anything. Thanks for the thorough review.

[sarveshpatil-plivo]

@710leo Are there any other changes to be made?
If not, can we go ahead with merging this PR.