Kill out-of-memory gears more aggressively to reduce downtime

This change does a few things differently:

* Make multiple attempts when reading or writing cgroup
  data, to get around lock contention.  Also, handle
  exceptions better in this process

* Avoid calling force stop on the gear, because this
  involves other possible locking problems, and almost
  never works on an OOM gear, even when we bump the memory
  limit.  This also eliminates the time window between
  stopped and started states where someone/something could
  execute a conflicting state change.

* Send kill signals before we bump memory, so that the
  existing processes should immediately start cleaning
  up when the memory limit is bumped, without doing
  anything else like accepting more connections.
bz1162474
if app_name different with app.name of uuid, throw out an warning
Revert "Add logging about idling/unidling in vhost plugin"

This reverts commit 6259fdf25cbb8f8a8d686d4958a4e5fed1d99e01.
Don't call unidle prematurely from GearStatePlugin

Fix bug in the Watchman gear state plugin that would incorrectly call
frontend.unidle for gears that were in the process of being idled.

During the idling process, the frontend marks the gear as idle, the
gear's state is set to STOPPED, the gear is stopped, and the gear's
state is finally set to IDLE. If the gear state plugin sees the gear
when its state is STOPPED, before it transitions to IDLE, it was
prematurely calling frontend.unidle, which resulted in the gear being
stopped but without any frontend configuration in place to call the
restorer to unidle when accessed via http.

Bug 1161165
Merge pull request #5950 from sztsian/bz1162474-keep

Merged by openshift-bot
Fix unit test for oom_plugin
Merge pull request #5951 from ncdc/bug/1161165-missing-idler-conf

Merged by openshift-bot
Analytics additions
Merge pull request #5910 from a13m/aggressive-oom-kill

Merged by openshift-bot
Merge pull request #5953 from danmcp/master

Merged by openshift-bot