Feature 256/deterministic iterator

[kuba--]

This is pretty radical change, so please review carefully. It's related to #256

What has been changed to avoid randomised order by Repository iterator:
Current implementation relied on multiple channels which were populated in constructor NewRowRepoIter.
First we iterated over repos and push them to repos channel, at the same time N go routines pulled repos from a channel, convert them to rows and pushed rows to the next channel.
At the end we had a channel with a mix of rows from different repos (multiplexed by go routines).

This PR drastically removes lot of complexity and make everything linear in the Next function.
We just iterate over rows till we get an EOF error, then we move to the next repo.
I left only one done channel for internal usage (mainly for tests' graceful shutdown) and context.
Also what's worth to notice are atomic operations in RepositoryIter.Next function to make the API thread-safe

[ajnavarro]

LGTM after @jfontan have a look on it.

[kuba--]

@jfontan - I think, I can also remove internal done channel. Actually we don't use it (only internally), so I believe ctx.Done() + io.EOF error are good enough.
Just to give you more insight. So far, in one of our test we have:

	go func() {
		for {
			_, err := repoIter.Next()
			if err != nil {
				break
			}
		}
	}()

	select {
	case <-repoIter.done:
	case <-repoIter.ctx.Done():
	}
	cancel()

If I remove done then this code will have to change but just a little bit (and will be even simpler in my opinion):

	go func() {
		for {
			_, err := repoIter.Next()
			if err != nil {
                                cancel()
				break
			}
		}
	}()

<-repoIter.ctx.Done()

WDYT?

[jfontan]

@kuba-- As you say we don't need done channel anymore. The proposed change to the test looks good. 👍