Adds an RWLock to protect replication from truncation.

[slackpad]

This is a very simple fix for the "replace single row lookups with multi row lookups" part of #84. I looked at extending the LogStore interface but it was awkward to do and added a lot of complexity, when a simple lock at this higher level adds protection without pushing any of those details downwards.

I'm thinking through a good way to test this, other than the current tests which are passing as a regression.

[slackpad]

@ongardie or @superfell I wanted to clarify the intent of the "verify the current term has not changed when preparing the AppendEntries message" companion item to this one from #84. It doesn't seem like we will spend much time preparing the AppendEntries message and the upper code that calls this will handle the leader stepping down on the next replication attempt. Was there a particular edge you were trying to catch with the additional check?

[ongardie]

@slackpad I think the main concerns were in the following sequences:

1. set AppendEntries previous log index + term
2. leader steps down
3. log changes
4. set AppendEntries entries

or

1. set AppendEntries previous log index + term
2. set AppendEntries entries[:x]
3. leader steps down
4. log changes
5. set AppendEntries entries[x:]

[ongardie-sfdc]

Looking at this again, I don't think we need or want the logsLock. I think re-checking the server's term will buy us more safety for the scenarios I mentioned in my last comment. So 👎 on this one. Let me give it a try in a later PR.

[slackpad]

Agreed - this isn't the right approach.