API to negotiate whether the validator will accept a channel, and API to submit channel info

[Ivshti]

since the ethereum channels can't be entirely collected from the blockchain, we need to be able to submit info about the channel to the sentry

we also need to be able to negotiate whether the validator will take the channel beforehand: for example, the validator should have a configurable threshold of funds/whitelisted tokens (see #30)

in practice, this should probably work like this:

• ask the validator whether they'd accept the channel; you'd send all info about the channel except the validators
• submit the channel, with full info; at this stage, we will know the channel hash

if the second operation fails for some reason, we repeat the whole thing

after the second operation, we should create some sort of a temporary record that will not be considered by the ticks and routes (https://github.com/AdExNetwork/adex-validator-stack-js/blob/master/bin/validatorWorker.js#L32 and https://github.com/AdExNetwork/adex-validator-stack-js/blob/master/routes/channel.js#L55) until the watcher approves it; otherwise, this record should also auto-expire; the watcher approval should happen when it sees the channel on the blockchain, possibly after having some # of blocks after as a safety threshold against block reorgs

[Ivshti]

Proposal for the API:

• POST /channels/campaign - takes {channel} - takes a full channel object with a campaignSpec property (as is usually returned by /channels; saves the channel in a pending state, with created; all channels that are pending for more than a week (actually, a configurable value) will be evicted by a query that's periodically done by the worker; this does not need to check if the channel is signed by the creator, because the channel will be upgraded to an active state only if it's found on-chain; before saving, we should check if (1) the channel is valid structurally, (2) it complies with our criteria (#30) as defined in the cfg and finally (3) set channel.id to a hash, as defined by the adapter (which would use hash here: https://github.com/AdExNetwork/adex-protocol-eth/blob/master/js/Channel.js)
• POST /channels/campaign-validate-query - takes {channel, role} - works similarly to the previous one, but (1) you always supply an empty array for validators and (2) it doesn't save the channel, but rather checks if this validator would accept it (for role where that is "leader" or "validator"); this depends on policies that will be defined in cfg, but in the beginning this would just be an optional whitelist of creators (if it's null we don't apply it), minimal deposit and whitelist of tokens (see #30)

The watcher's job is, per tick, to get all new on-chain channels, match them against channels that are pending with the same channel.id, and if there's a match, change that channel state to active. It will also periodically evict all pending that are older than a configurable threshold (e.g. a week)

This will in turn trigger the validator worker ticks, including #17

The full flow would be:

1. dApp user picks advertiser/publisher nodes
2. They negotiate with these nodes whether they'd validate their campaign via POST /channel/campaign-validate-query; if something goes wrong, go back to step 1
3. They post the campaign via POST /channel/campaign
4. they submit the channel on-chain
5. Each validator's watcher will see the channel on-chain, match it against the submitted channel info (campaign) and change it's state to active
6. once it's active, each validator will start processing this channel in their tick, therefore emitting Heartbeat #17
7. once the user observes that all validators are emitting a heartbeat, they will see that the campaign is now live
8. this has other consequences too: the Market will register this, and so the campaign will start appearing in the dApp, in the Explorer and will start getting considered by the SDK