Review integrations code for consistency

[siavashs]

Example: use payload instead of request:

// payload is the payload sent to mattermost's incoming webhook API.
// https://developers.mattermost.com/integrate/webhooks/incoming/#parameters
type payload struct {

Originally posted by @siavashs in #4090 (comment)

[TheMeier]

I dug around a it in the notifiers and they are very different. Just renaming the struct representing the message content to send to payload might not cut it. Instead we could think about a naming scheme maybe like it is used in the opsgenie notifier. It has opsGenieCreateMessage, opsGenieCloseMessage, opsGenieUpdateMessageMessage (double Message?) and opsGenieUpdateDescriptionMessage

A possible naming scheme modeled like that would be roughly this <notifierName><OperationType>Message

So for example in the mattermost case mattermostSendMessageor matterMostPostMessage. For MS-Teams teamsMessage would become teamsPostMessage. For rocketchat PostMessage would become rocketchatPostMessage

But actually the <notifierName> prefix should not really be required since this is already encoded in the go package name. Eg the webhook notifier simply calls is Message at the moment.

Also this idea doesn't really apply to notifiers which are more than a simple single POST.

Another observation a couple of these types in the notifier implementations are exported though it is not needed.

[siavashs]

In this specific case it was what Mattermost calls it.
Basically integration should try to use the same terms and naming as the upstream docs to make sure it would be easier to maintain in future.

But I think all the points you raise are also important.
Notifier integration have to support the expected public API, but they currently might expose thing that are needed, etc.
We probably need a linter to catch these.