Potential bogus epoch notification?

Description of the bug
https://github.com/oasislabs/ekiden/blob/2cb41bfab18c7e34288e476b3a7a3f12fbb7fd47/go/epochtime/tendermint/tendermint.go#L115

If tendermint.New(...) were to be invoked to create a new tendermint-backed epoch time service and a client were to invoke WatchEpochs() before the worker thread has gotten any new blocks -- and update epoch and lastNotified members from the default zero values, then it appears that the new subscriber callback function argument to NewBrokerEx on L111 will see that r.epoch and r.lastNotified are identical (both zeros), and invoke ch.In() <- r.epoch and send the zero value as a legitimate epoch value.

This is only from a reading of the code, and should be verified that there is indeed a race.

Steps to reproduce

1. Read the code. Rest is hypothetical.
2. Use a mock tendermintBackend or TendermintService that ensures that the worker thread will not actually get an updated epoch
3. Subscribe via WatchEpochs and receive an epoch from the channel.

Expected behavior
Either document that a spurious zero epoch value is possible and that the client should discard, or ensure that we suppress it. Unless zero is actually legitimate, in which case we should have a boolean flag or something like that to ensure that the epoch and/or lastNotified members are legitimate, or something along those lines.

Environment

• OS:
• Versions of relevant software and tools:

Additional information

Start at go/epochtime/tendermint/tendermint.go around lines 111-115 and trace NewBrokerEx, WatchEpochs, and worker initialization. Reproduce with a mock backend that delays the first block, then confirm whether a zero epoch is delivered before a real epoch; done means the behavior is verified and either suppressed or explicitly documented.