[FIXED] Panic after hash check and concurrent compact

[MauriceVanVeen]

In rare edge cases the server could panic here:

	if !hashChecked {
		mb.cache.idx[seq-mb.cache.fseq] = (bi | cbit) // <----
	}

[WRN] Catchup for stream '$G > test-stream' resetting first sequence: 1064 on catchup request
...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xb7071d]

goroutine 91 [running]:
github.com/nats-io/nats-server/v2/server.(*msgBlock).cacheLookupEx(0xc0003ca000, 0x42c, 0xc000c42890, 0x1)
	server/filestore.go:7924 +0xfdd

This was likely due to the defer smb.finishedWithCache() which sets mb.cache = nil without holding the lock if a fs.compact ran concurrently while the hash needed to be checked when looking up a message for that same block.

Signed-off-by: Maurice van Veen github@mauricevanveen.com

[neilalexander]

LGTM