Actions :: actionWatcher consume initial events

... safely, by accounting for potential race condition between
registering the watcher and finding previously queued actions
use short decl for initial and err per code review comments
Merge branch 'master' into actionwatcher-initial-events
Updated bodie's test to reflect this PR
Merge pull request #275 from johnweldon/actionwatcher-initial-events

Actions :: actionWatcher consume initial events

Context
---
When a `watcher` is started it registers with the `state.watcher` to be notified when changelog items matching it's filter are detected.  The `state.watcher` does this by periodically looking through all the new changes in the mongo changelog and feeding appropriate events to all of the registered watchers.

When an `actionWatcher` is first started, we want to not only be notified of new actions being added to the `state.actions` collection, but also of any actions added to the `state.actions` collection before the `actionWatcher` was started.

This is done by querying the state.actions collection in the initialization of the `actionWatcher`, and pre-loading those actionId's into the changes buffer before the watcher loop starts.

This is a common idiom in several of the watchers.


Problem
---
It is possible when the `state.watcher` has been running for more than a few seconds (i.e. in long running tests, or the real world, but not in normal short running tests), that between the time the `actionWatcher` is started, and the `state.watcher` begins notifying the `actionWatcher` of changes, that an action may be added to the `state.actions` collection.

In this case the pre-loaded actionId's could be sent once from the initially loaded changes buffer, and then again when the `state.watcher` detects and notifies the `actionWatcher` of that addition.

However, this is somewhat race-ey.  If the timing is different and the goroutines run in a different order then the pre-loaded actionId's will only be sent down once.


This PR's Solution
---
In this PR we are caching only those pre-loaded actionId's and then filtering subsequent notifications by removing these specific actionId's, since we know they have already been sent.

This is not too bad of a solution; we're not caching *all* of the previously seen actionId's, only the ones vulnerable to this race condition.

The alternative seems way worse, which would be to ask the `state.watcher` what the last changelog number it processed was when we initially register the watcher, and then only pre-loading actionIds that came before that changelog number.  I don't like that option because we're exposing previously internal details of the `state.Watcher` to the `actionWatcher`.
Fixed up ActionEvents worker/uniter/filter tests to reflect AddAction changes
Fixed test behavior of worker Filter to account for change to Action query
Added filter test to ensure pre-queued Actions are properly received on worker event filter
Removed deduplication of Action events from worker uniter filter
Merge pull request #163 from binary132/action-filter-dev

worker ActionEvents filter

Requesting comments, especially on tests.  This branch includes some commits which are waiting on PR 140 and 141 to land, but the API should not change.

I'm not positive this exercises all possible cases; I'm also planning to add a 1-2 second delay in the event consumer loop so we can test adding actions midflight.

All input welcome!