Patch in https://github.com/dgraph-io/badger/pull/1313 to fix GC after restore.

[avinashparchuri]

This is a patch of dgraph-io#1313; While the original patch indicates that the fix should only be applicable when oldOptions.ValueThreshold < newOptions.ValueThreshold, we seem to hit this case in other situations as well, this patch fixes GC on our restored DBs (I've also verified the # of doc-ids per-corpus after restore).

I've been unable to reproduce this case in our unit-tests (i.e keeping ValueThreshold the same between backup/restore) - my suspicions are on some interaction between GC and the restore, but this has been hard to replicate/reproduce.

The other option is to just upgrade to mainline v2.2007 - it looks like it contains a bunch of other fixes that we probably want as well (and which might also be playing a part in causing these inconsistent value-pointer bits):

• Fix for transactions when using iterators: Iterator: Always add key to txn.reads dgraph-io/badger#1328
• Fix for purging expired keys & deletion markers: levels: Expired keys and delete markers are never purged dgraph-io/badger#1354
• Avoid re-writing move-markers for deleted keys: Confirm badgerMove entry required before rewrite dgraph-io/badger#1302

It is a bit more risky to upgrade (ex: we may see a recurrence of the GC issues; mainline v2.2007 is still using an older version of Ristretto, whereas our fork seems to have been upgraded), especially given that this will be the first time we will be exercising the restore path for prod-instances, but we could save time and just do the upgrade now, rather than having to revisit later.

[asimshankar]

Cool find!
My gut feeling is that ideally we'd upgrade only after we've been able to successfully been able to restore existing backups. That way we'd have the ability to at least go back to backup if the upgrade causes trouble.

However, not sure if we're going to get to that state :). 🤞🏾 that this works.