Refactor http-based alarm plugins and extract common logic to HttpAlarmCallback

[kezhenxu94]

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.

[wu-sheng]

I think we should expose this. We can't make sure HTTP endpoint using JSON format.

[kezhenxu94]

I think we should expose this. We can't make sure HTTP endpoint using JSON format.

This is not "make sure", it's a preference here, this means the client (us, OAP) prefers json response, and if the server can provide the response in JSON format, it will send the JSON in high priority, otherwise the server will send whatever format it can. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation

[kezhenxu94]

you can test this with

curl -H"Accept: application/xml" https://httpbin.org/json

It won't return xml, it will still return json

[wu-sheng]

I know this is flexible for most time, but I really had seen some notification server has very strict rules to check and parse data.
I just recommend we should have the post method to expose this, and add a postJSON to lock this to be convenient for callbacks.

[kezhenxu94]

I just remove this header directly... it's never used in our alarm plugins, and it's seldom used in my opinion, also if in the future we need, we can simply pass in the headers argument of this method.

[kezhenxu94]

@wu-sheng mind taking another look?