Make ValidationContext and ExecutionContext implement the ICS-26 router

[plafer]

When we wrote ADR 5, we forgot to consider how the ICS-26 router would work with the new ValidationContext and ExecutionContext. Also, since then, the removal of crossing hellos from connection and channel handshakes changed how certain handlers interact with the router (e.g. we can no longer emit events directly in ChanOpenTry and ChanOpenAck handlers). This issue serves to amend ADR 5 in order to address all of the above.

The bottom line is: both validate() and execute() need to perform the relevant parts of the ICS-26 router. As an example, here is what validate() and execute() would do to handle a ChanOpenTry message:

• validate():

  1. Get the associated Module based on the msg.port_id
  2. Call the core chan_open_try::validate() handler
  3. Query the host for the channel_id (through the channel counter)
  4. Call the Module callback on_chan_open_try_validate() (which only performs validation)

• execute():

  1. Get the associated Module based on the msg.port_id
  2. Query the host for the channel_id (through the channel counter)
  3. Call the Module callback on_chan_open_try_execute(channel_id, ...) (which only performs state changes), and save the returned version
  4. Call the core chan_open_try::execute(version, ...) handler, feeding it the version obtained from the execute() callback

A few things to note:

• we need to extend the Module trait with validation methods (1 per callback).
• The channel_id is no longer generated by the core handler, as specified in the specs (although see this spec issue which shows that the spec needs to be updated). Instead we generate it in what is effectively the ICS-26 router.

[plafer]

Blocked on #361.