Enable FSM batching through optionally implemented interface

[briankassouf]

Currently this library operates under the assumption that the FSM apply will be much faster than the Log apply. Based on this assumption the library does Log apply batching but no FSM level batching. When using an in-memory FSM this isn't a problem, but when the FSM is doing additional work- such as persisting the data to disk- this causes high latencies.

This PR introduces a new BatchingFSM interface which extends the FSM interface to add an ApplyBatch([]*Log) []interface{} function. This can optionally be implemented by clients to enable multiple logs to be applied to the FSM in batches. Up to MaxAppendEntries could be sent in a batch.

ApplyBatch is invoked once a batch of log entries has been committed and are ready to be applied to the FSM. ApplyBatch will take in an array of log entries. These log entries could be of a few types so clients should check the log type prior to attempting to decode the data attached. Presently the LogCommand and LogConfiguration types will be sent.

The returned slice must be the same length as the input. The returned values will be made available in the ApplyFuture returned by raft.Apply method if that method was called on the same Raft node as the FSM.

[banks]

Great work Brian!

A couple of pretty minor thoughts inline but overall this looks great.

I know we recently got fuzzy working again, is is worth adding a fuzz test that exercises batched FSM to get more confidence we haven't violated the FSM invariants in face or concurrent operation ans errors?

[banks]

Amazing!

Separate PR for the existing metric makes sense - would be good to do that soon though so our products can end up with consistent metric types in next release. We should also make sure to document in CHANGELOG for raft and notify our own teams so they can note the change in metric type for their release notes.