Refactor redis brain storage of incident data

[jm-welch]

The current storage structure for incident data in the redis brain looks like this:

{
  "users": {
    "1": {
      "id": "1",
      "name": "Shell",
      "room": "Shell"
    },
    "jmwelch": {
      "id": "jmwelch",
      "name": "jmwelch",
      "roles": [
        "admin",
        "oss"
      ]
    },
    "VictorOps": {
      "id": "VictorOps",
      "name": "VictorOps"
    }
  },
  "_private": {
    "1091": {
      "#ALERT JSON FOR 1091 HERE"
    },
    "1092": {
      "#ALERT JSON FOR 1092 HERE"
    },
    "VO_INCIDENT_KEYS": []
  }
}

This seems redundant. Rather than writing one list that we then use to prune items from a separate dict, we should just maintain a single dict. The reason for the VO_INCIDENT_KEYS branch seems to be to allow us to timestamp items as we receive them, so that "old" items can be removed, but the TIMESTAMP value within each incident's JSON data should serve the same purpose.

I'd propose that this be restructured to look like this:

{
  "users": {
    "1": {
      "id": "1",
      "name": "Shell",
      "room": "Shell"
    },
    "jmwelch": {
      "id": "jmwelch",
      "name": "jmwelch",
      "roles": [
        "admin",
        "oss"
      ]
    },
    "VictorOps": {
      "id": "VictorOps",
      "name": "VictorOps"
    }
  },
  "_private": {
    "VO_INCIDENTS": {
      "1091": {
        "#ALERT JSON FOR 1091 HERE"
      },
      "1092": {
        "#ALERT JSON FOR 1092 HERE"
      }
    },
    "VO_CONTROL_CALL": {
    }
  }
}

I added the CONTROL_CALL branch, as that's the next big thing I'm working on, and an example of data that would be useful to store, but more clumsy to access/iterate over if all the incidents are stored with it at that level in the data struct.

This will involve rewriting a couple of small pieces of the adapter, but should be doable. I'm already working on a rewrite, but won't have results until I finish my testing on #13.

Only major consideration at the moment is whether this is more computationally costly than the current method, as we'll be iterating over a dict of variable-size dicts, instead of a list of two-value dicts. I'm honestly not sure how to do performance benchmarking in coffeescript/nodejs, so once I have something working, I may need some help figuring out how to test that part.