Avoid holding batchCond while dispatching updateInterrupt

[peterbroadhurst]

In #162 there is the following deadlock:

Deadlock investigation

Batch processor trying to notify eventPoller to stop using updateInterrupt:

goroutine 547 [chan receive]:
github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).batchProcessor(0xc0001be160)
	/ethconnect/internal/events/eventstream.go:544 +0x11b
created by github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).startEventHandlers
	/ethconnect/internal/events/eventstream.go:209 +0x10c

firefly-ethconnect/internal/events/eventstream.go

Line 544 in d686811

<-a.updateInterrupt

Event poller trying to obtain the batchCond:

goroutine 546 [semacquire]:
sync.runtime_SemacquireMutex(0xc000028334, 0xbc8800, 0x1)
	/usr/local/go/src/runtime/sema.go:71 +0x47
sync.(*Mutex).lockSlow(0xc000028330)
	/usr/local/go/src/sync/mutex.go:138 +0x105
sync.(*Mutex).Lock(0xc000028330)
	/usr/local/go/src/sync/mutex.go:81 +0x47
github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).isBlocked(0xc0001be160, 0xc000292030)
	/ethconnect/internal/events/eventstream.go:356 +0x5c
github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).eventPoller(0xc0001be160)
	/ethconnect/internal/events/eventstream.go:393 +0xd85
created by github.com/hyperledger/firefly-ethconnect/internal/events.(*eventStream).startEventHandlers
	/ethconnect/internal/events/eventstream.go:207 +0xcc

firefly-ethconnect/internal/events/eventstream.go

Line 356 in d686811

a.batchCond.L.Lock()

... called from this loop:

firefly-ethconnect/internal/events/eventstream.go

Line 393 in d686811

if err == nil && !a.isBlocked() {

... which is where we would pull from the updateInterrupt

Proposed fix

Release the batchCond lock, before consuming from the updateInterrupt channel

[vdamle]

Suggested change

	a.updateWG.Done() //Not moving this to a 'defer' since we need to unlock after calling Done()
	a.updateWG.Done()

[vdamle]

Removed the stale comment

[peterbroadhurst]

Build hit the same issue from #166, so pulled in the verbose test running from that change to see if I can catch it here.