[large-tiles] Cross block reader changes plus Cross block iterator

[linasm]

What this PR does / why we need it:
Latest version of CrossBlockReader, plus CrossBlockIterator.

Special notes for your reviewer:

Does this PR introduce a user-facing and/or backwards incompatible change?:
NONE

Does this PR require updating code package or user-facing documentation?:
NONE

[arnikola]

I think this would be clearer as

if c.idx < 0 {
 return c.current.Next()
}

if c.current.Next() {
 return true
}

// NB: clear previous.
// ...
return c.Next()

[linasm]

Not exactly. I have to invert the condition for the early return true, and make sure that the call to c.current.Next() gets short-circuited away if c.idx < 0, like this:

	if c.idx >= 0 && c.current.Next() {
		return true
	}

...

[robskillington]

Any reason to use indices instead of just references to the readers themselves?

i.e.

dataFileSetReaders   []DataFileSetReader
pendingDataFileSetReaders   []DataFileSetReader

[robskillington]

(not saying we should change it, just curious as to one vs other approach and whether you think there's advantages to one or the other, typically we've done the latter elsewhere so you can directly call methods on the references instead of then indexing into the other slice and you have slightly higher memory temporal locality due to not bouncing between the slices)

[linasm]

I guess the only reason is that then I would have to put a DataFileSetReader into a minHeapEntry which I wanted to keep just a clean value object.

[linasm]

Also, as you noticed, minHeapEntry.dataFileSetReaderIndex is used for ordering of the minHeap (to break the ties when the ids are equal), so I would need to have two values in order to follow your suggestion. Guess will leave this as is.

[robskillington]

Hm, I thought we had put in protection to see if entry.Offset+entry.Size isn't out of bands here? Looks like we don't have any here, should we add it?

Ah I see we removed it, can we add it back in? (that is if entry.Offset+entry.Size > int64(len(r.dataMmap.Bytes)) {)

[linasm]

My bad, looks like this was lost during merge conflict resolving.
Will fix this, and also go through the comments from the last PR on these files, to make sure nothing else is missing.

[linasm]

Resurrected the bounds check on mmaped bytes, also checked the status of other comments after the merge, didn't notice anything else that would be missing.

[robskillington]

LGTM