See rabbitmq/gen-batch-server#25.

Bump `gen_batch_server` to `0.9.1`

The catch expression captured the full exception term including
the stacktrace, which could contain the entire Ra server state
in its function arguments. Logging this with ~p caused
io_lib_pretty to traverse the massive term, triggering extreme
memory allocation and OOM crashes for servers with large machine
states (e.g. millions of messages).

In this case the node crashed due to OOM because there was a
function_clause error in the state machine implementation where the
state machine had a huge state.
We still need the stack trace to locate where the function_clause
originates from.

Replace catch with try/catch in handle_leader/2

update_segments/2 used the `--` operator to compute which new segment
files should be deleted as overwritten.  `--` performs exact tuple
matching, so when compact_segrefs/2 *limited* (truncated the end index
of) a segment rather than removing it entirely, the limited tuple
{Fn, {Start, NewEnd}} no longer matched the original
{Fn, {Start, OrigEnd}}.  The original was then incorrectly included
in OverwrittenSegments, causing the segment file to be deleted while
a reference to it remained in the segment_refs structure.

This manifested when the segment writer sent a batch containing both
normal (4096-entry) segments and compacted (wide-range) segments whose
index ranges overlapped.  compact_segrefs would limit the compacted
segments, and the `--` operator would flag them as overwritten.  The
files were deleted, leaving dangling references that caused subsequent
reads to fail with "did not found all requested indexes".

Replace the `--` approach with a map-based filename lookup: build a
set of filenames surviving in the compacted result and only flag
segments whose filename is completely absent — i.e. truly removed,
not merely limited.

Fix segment file deletion for limited (range-truncated) segrefs

This will be useful to Ra machine implementations to include this value
in their snaphsot decision.

The snapshot module implementation can now return the size of the
snapshot from its `write/4` callback with `{ok, SnapshotSize}` where
`SnapshotSize` is a non-negative integer representing the number of
bytes of the snapshot.

To maintain backward compatibility, returning the historic `ok` value is
accepted. In this case, the snapshot size is set to `undefined`.

Likewise, when a snapshot is recovered, a new optional snapshot module
callback is used, `get_size/1`. If the callback is unimplemented or if
the callback returns an error, the snapshot size is set to `undefined`.

Note that this commit only adds the tracking, not the query API. This
will be added in a follow-up commit.

This will be useful to Ra machine implementations to include this value
in their snaphsot decision.

ra_snapshot: Track latest snapshot size in bytes in state