storage: avoid unmarshaling snapshot data in Store.canApplySnapshot

[petermattis]

Store.canApplySnapshot unmarshals the snapshot data (roachpb.RaftSnapshotData) in order to access the roachpb.RaftSnapshotData.RangeDescriptor which is needed for the range start and end keys. The RangeDescriptor is small in comparison to roachpb.RaftSnapshotData. We could either replicate it in RaftMessageRequest or include the start and end keys (i.e. a roachpb.Span) in RaftMessageRequest whenever a snapshot is present.

[bdarnell]

We could also unmarshal into a partial message type:

message PartialRaftSnapshotData {
  optional RangeDescriptor range_descriptor = 1 [(gogoproto.nullable) = false];
}

By using the same tag numbers (and disabling unrecognized-field support), we can parse just the parts we need and skip over the rest (although just skipping over all the KV pairs takes time, so we'd be saving memory more than CPU).

[tbg]

cc #7830 since a solution proposed there (range reservations) would play along nicely as a container for the unmarshaled snapshot.

[rjnn]

Partially addressed in #8365, via the strategy described in @bdarnell's comment above, but leaving this issue open as we should aim to only unmarshall the snapshot once.

[bdarnell]

This has been fixed with streaming snapshots; the range descriptor is now transmitted separately from the bulk of the snapshot data.