broker: add optional ReadRequest.BeginModTime constraint

[jgraettinger]

If provided, the broker read API will skip the read offset over persisted fragments having a modification time that falls before the bound. This can be used to efficiently skip over undesired historical prefixes of journal content given a wall-time lower bound.

---

This change is 

[jgraettinger]

Tested end-to-end using file:// stores on a (modified) Flow local stack.

[psFried]

LGTM
I thought of a corner case, and not really sure if we should do anything to handle it:
Suppose I've gone back and edited a fragment back in the history.

/fragment-01 (mod-time 1)
/fragment-02 (mod-time 9) <- edited this one
/fragment-03 (mod-time 3)
/fragment-04 (mod-time 4)
/fragment-05 (mod-time 5)

Now I issue a read request with ModTime: 4. As I understand it currently, we'd end up serving them fragments 02, 04, 05, and skip over 03. I think this seems fine, since the client would be doing its own filtering based on timestamp. But I wanted to ask just in case clients can't effectively deal with skipping a fragment like that. Is there any way for that to cause an issue with a sequencer or something?

[jgraettinger]

I thought of a corner case, and not really sure if we should do anything to handle it:
Suppose I've gone back and edited a fragment back in the history.

Yep, that's fine. This is why the contract is "you won't get fragments who's store modification time is before BeginModTime", not "you won't see data written before BeginModTime. Clients are required to filter if they want the second meaning. This is only an optimization that can cut out a lot of data that's trivially proven to be before the time of interest.