fix: Fix race condition in block.incRef

[jarifibrahim]

Fixes hypermodeinc/dgraph#5456 .

This PR fixes the crash that could occur when a block was read from the cache.
There was a logical race condition. The following sequence of events could occur which would cause the crash.

1. An iterator makes t.Block(idx) call
2. The t.Block function finds the block in the cache. The newly found block has ref=1 which means it was held only by the cache.
3. The t.Block function is holding the block and at the same time the block gets evicted from the cache. The existing ref of the block was 1 so the cache eviction would decrement the ref and make it 0. When the ref becomes 0, the block is added to the sync.Pool and is ready to be reused.
4. While the block got evicted from the cache, the iterator received the block and it incremented the ref from 0 to 1 and starts using this.

Since the block was inserted into the syncPool in the 3rd event, it could be modified by anyone while the iterator is using it.

The fix is to not increment the block ref if it is already zero.

---

This change is 

[gja]

prefer if you name this to add random

[manishrjain]

Reviewed 3 of 3 files at r1.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @ashish-goswami and @jarifibrahim)

---

table/table.go, line 196 at r1 (raw file):

		ref := atomic.LoadInt32(&b.ref)
		// The ref would not be equal to 0 unless the existing
		// block get evicted before this line. If the ref is 0. it means that

If the ref is zero, it means

Do mention that we can't just blindly add 1 to ref. We need to check whether it has reached zero first, because if it did, then we should absolutely not use this block.

---

table/table.go, line 451 at r1 (raw file):

		blk, ok := t.opt.Cache.Get(key)
		if ok && blk != nil {
			b := blk.(*block)

if b := ..; b.incrRef() { return b }

[jarifibrahim]

All review comments have been addressed.