Abstract notifications event channel

[tortillaj]

@tizzo @lliss (and anyone else!) -

Currently, this service is reading off the specific, build_events channel. When a new build event is received, the type of desired notification is read off its configuration (which is received from the .probo.yml).

I'm floating the idea of altering this service so that it listens to an abstract, notifications event channel. An individual event on this channel might look something like this:

{
  type: 'webhook', // or email, slack, sms, carrier pigeon
}

Each type of notification is already planned to be a separate plugin, within this service. Also, each of these types will need their own settings. For example, to flesh out the webhook example:

{
  type: 'webhook',
  recipientUrl: ['http://one', 'http://two'],
  message: 'Build 123456789 has passed! View your build here: https://123456789.probo.build',
  data: buildObj,
  status: 'success',
}

Basically, this service is simply a delivery system for notifications. It is provided any and all parameters in their finalized form. (Notice the message property above already has the build id and link)

That said, each plugin will have its own requirements for how a notification is formatted. For example, Slack will need its data posted in a specific format, and email notifications will have some HTML template that contains the passed parameters. This plugin specific processing happens in this library.

Benefits of this change

1. This service is simplified. It doesn't care about anything other than feeding notifications to places, and probably reporting back if it didn't work.
2. This service can be used to send notifications for anything, instead of just build events. For example, we can send out Stripe warnings or payment information. Perhaps Probo HQ will want to send notifications to its clients for some reason (e.g. Probo downtime).

[tizzo]

This raises some interesting questions. I was making this service pretty smart - it evaluates the build object and decides what the notifications should look like and to whom they should be sent. This proposal would, I suppose, make it dumb and move that logic to wherever these events are being originated (or some intermediary in some cases?).

I'll need to give this some thought. +1 to adding a carrier pigeon plugin though - for sure - carrier pigeons are awesome. Maybe we can use PigeonGram.