PR-1455: Update perfmon wrt the new alert priority grade

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Remove VMPP specific mail-alarm code

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Revise default priority threshhold in mail-alarm

  * The previous PR-1455 work changed from mail-min-prioirty to mail-max-priority. I believe this is an unnecessary change that break backward compatability. "mail-min-priority" can literally mean the lowest message priority level to trigger an email alert. Which direction (greater value or smaller value) is lower is up for interpreation.
  * With PR-1455 definition, priority value between 1-3 will require actions, hence change the mail-min-priority threshhold to 3.

We should probably document this mail-min-priority config as part of PR-1455 doc in the release note (for incomptabile changes to the alert system in general).

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: rewrite message priorities online during rolling pool upgrade

During rolling upgrade, upgraded master might have an alerts grading system different from the not yet upgraded slaves. During this process, as a special case, we transform the priority of a received message (if the message belongs to the standard messages set).

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Move some code from Xapi_message.create to Xapi_message.write

... so that we can reuse them when calling Xapi_message.write directly.

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: rewrite message priority values during upgrade.

A host post-upgrade might have different priority on messages from pre-upgrade. In order to reduce confusions (e.g. messages with the same code before and after upgrade shown together with different priorities),  here we convert the messages pre-upgrade to use the new priority values.

We are using a very straightforward algorithm here: destroying a old message and recreating a new one keeping most of the settings untouched but the priority. A more elegant solution would be creating facilities to upgrade an existing message rather than destroy/recreate one. In fact, I was half way on that solution but decided to take the no so elegent but simpler approach. The straightfoward implementation can avoid many of the complexities because messages are not part of the datebase hence many things have to be updated manually (e.g. event, gen, symlink). It's much reliable to reuse the existing facilities rather than creating the new ones.

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Update pool's other-config:mail-min-priority to the new alerts grading system

Users were allowed to set the mail-min-priority to arbitray value before, so there isn't a definitive algorithm to map the setting to the new alert grades. This is just one reasonble way making the transformation:

Given previous mail-min-priority = n

    n > 10       ->  0
    n = 10       ->  1
    5 < n < 10   ->  2
    n = 5        ->  3
    1 < n < 5    ->  4
    n <= 1       ->  5
    unrecognized ->  remove (reset to default)

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
Merge pull request #1210 from zli/xenserver/PR-1455

xenserver/PR-1455