Use constant lock expiration for all hash-time-locks of the same transfer

[hackaugusto]

In the first interation of Raiden unlock had to be called on a per
channel basis, and the operation was only allowed for a channel on the
closed state. Because the unlock was on a per channel basis, every
mediator had to use a lower expiration for the lock it sent in respect
to the lock it received.

The hash-time-lock expiration was always decrease by a configuration
variable named reveal timeout, the setting was in number of blocks, and
represented how many blocks were required by the node to learn about an
on-chain unlock on the payee channel, and call unlock on the payer
channel. The reveal timeout setting included how many blocks the node
requires to learn about a new confirmed block, for the payee unlock,
plus how many blocks were required to successfully mine two
transactions, the close and the unlock on the payer channel.

The above dynamics changed with the introduction of the secret registry.
With the secret registry the channel no longer needs to be closed in
order to call unlock, once the secret is registered this information can
be used by the channel smart contract to unlock the any hash-time-lock
on-chain. Additionally the secret registry allowed the lock for *all*
mediators to be unlocked at the same time, this difference turns out to
be crucial.

With the secret registry, the semantics of the reveal timeout changed
from the time to learn about a new block and to mine two trasanctions,
to just the time required to mine the secret registration transaction.

The secret registration happens if a node learns about the secret
off-chain while the hash-time-lock is in the danger zone, where the
danger zone is a block close enough to the lock's expiration in which it
may take too long for the secret to be registered in time, becaase of
the risk of losing the payment, the node must send a transaction to
register the secret on-chain.

The above means a node will send a secret register transaction
regardless of how many blocks are left for the expiration of lock, be it
unhappy case of a single block or the happy case of `reveal_timeouts`
blocks. The rationale is that a node wants to receive the payment, and
if the locks is nearing expiration it should try to register the secret
to secure the payment. (Note that the unhappy case can be improved, but
the race condition cannot be fixed)

As a consequence, if the lock expiration decreases through the route, as
it was done with the first iteration, the secret registration may happen
too late for hop which sent the transaction, but soon enough for
previous hops. This means that for a path like A-B-C, the node C can
learn about a secret at block `n` which is `5` apart from the lock's
expiration, and the transaction can be mined at block `n+6`, C will not
receive the payment but if the lock expiration for A-B was larger B can
receive the payment.

The fix is to make lock's expiration constant. The initiator is
responsible to choose a value that is sufficiently large to allow a
transfer to be routed through the network without expiring, and low
enough so that it's not reject by too many channels with a low
settlement timeout. Once the target receive the hash-time-lock it must
include the lock's expiration in the secret request, which in turn is
verified by the transfer initiator, where it's of interest of the
initiator to make sure the expiration was constant through out the path,
otherwise the target would be at risk of not receiving the transfer.

[LefterisJP]

Isn't this fixed via #2224 ?

[palango]

Yes, think so.