☂️ Refactor the watcher for IoT use cases

[manoranjith]

Context

Currently, the watcher is associated with and coupled to a channel. One local instance of watcher must be started for each channel.

However, for the use case of IoT use cases (described in proposal#3), it is desirable to have a watcher that can

1. Run either locally or as a remote service.
2. Is not associated with any specific client/channel. Channels can be associated with/dissociated from a watcher dynamically during runtime.

The design for such a watcher was described in proposal#4. This is an umbrella issue to cover the changes for refactoring the watcher component based on the design in the proposal.

Details

Changes required in usage of watcher

1. Earlier, user need not initialize a watcher. But now, they should initialize and pass it on as an additional argument to client.New.
2. Usage of watcher will remain the same. User should call ch.Watch() in a go-routine after establishing the channel.

Preparatory steps

• 1. Adjudicator.Subscribe should take only ch.Id as a parameter instead of channel.Params. As the ID is sufficient for subscribing to events on the blockchain (Adjudicator.Subscribe takes channel.Params while only channel.ID is needed #173).

• 2. Define smaller interfaces for methods in Adjudicator (Define smaller interfaces for methods in Adjudicator #184).

Implementation steps

• Set 1 (Implement the local watcher #174)

1. Define the interfaces for watcher in go-perun/watcher package.
2. Implement a local watcher in go-perun/local package.

• Set 2 (Integrate statesPub interface into client. #197, part1)

1. Add statesPub field and setStatesPub method on watcher and call ch.statesPub.Publish whenever a new state is created.

• Set 3 (Integrate statesPub interface into client. #197, part2)

1. Update the client.New API to take a new watcher instance and store it.
2. Update the ch.Watch function to use the watcher instance stored in the client.

[matthiasgeihs]

Resolved by #248