opt(rollup): change the way rollups are done

[jarifibrahim]

Fixes DGRAPH-2608

ISSUE:
In a load that has a lot of updations to a key, a lot of deltas accumulate over time. These keys are added to the batch for a rollup. Due to the lossy behavior of rollups, they get dropped while the dgraph is busy rolling up keys (that might have much smaller delta count).

Fix:
This PR changes the way rollups are done.

• We now add keys to rollupBatch just after pushing the deltas over to badger.
• We now have a priority inside the keys that we rollup. The keys for which the deltas have increased up to a certain limit (hard-coded 500), we add it to high priority rollupKeyPool so that it has high chances to get rolled up and does not get dropped due to lossy behavior of rollups.

Results:
With a workload where a set of values are frequently updated:

• On master, the p directory size roars up to 6-7GB within 7-8 hours, and the deltaCount increases to 7-9k for lots of keys.
• On this branch, p directory size stays bounded in range 1-2GB even after >24 hours of workload.

---

This change is 

[jarifibrahim]

LGTM. @NamanJain8 is the disk size bounded after this change?

[jarifibrahim]

This PR needs a proper title and description.

[manishrjain]

Just some comments.

Reviewed 1 of 3 files at r5, 1 of 1 files at r6.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @ahsanbarkati, @jarifibrahim, @martinmr, and @vvbalaji-dgraph)

---

posting/mvcc.go, line 136 at r6 (raw file):

	doRollup := func(batch *[][]byte, priority int) {
		currTs := time.Now().Unix()

forcerollup is good to have. Use it over the priority pool.

Maybe add a TODO about dealing with opRollup not running.

[NamanJain8]

LGTM. @NamanJain8 is the disk size bounded after this change?

Yes, it is. Mentioned that in PR description.