opt(predMove): hot tablet move

[NamanJain8]

Currently, the writes are blocked on the tablet that is being moved. Shard movement can take a while (say 30 mins) to be moved completely. Then, its not a good idea to block the writes on that predicate.

Solution: Hot Tablet Move

1. Don't block initially. Do majority of the move first.
2. Block commits. Do incremental move. Resume commits.

TODO: Fix the issues found while working on this.

1. If a drop operation is triggered while the tablet move is in progress, the drop succeeds and we end up in an inconsistent state.
2. There is a corner-case, where an indexing operation might succeed before the tablet has moved completely. Once, the tablet move is complete, the indexing goes away, leading to a bad user experience.

---

This change is 

[manishrjain]

Reviewable status: 0 of 4 files reviewed, 2 unresolved discussions (waiting on @NamanJain8)

---

dgraph/cmd/zero/tablet.go, line 179 at r1 (raw file):

		SourceGid: srcGroup,
		DestGid:   dstGroup,
		TxnTs:     ids.StartId,

Rename it to ReadTs.

---

worker/predicate_move.go, line 97 at r1 (raw file):

						return errors.Errorf("Expecting clean predicate instruction with schema key: %+v", kv)
					}
					kv.Meta = nil

Use stream_id.

if stream_id == 0, then do the clean up.
If stream_id == 1, then don't.

You can then create an enum or something to set the stream id, so it's clear to the code reader.

[ahsanbarkati]

Reviewable status: 0 of 4 files reviewed, 3 unresolved discussions (waiting on @NamanJain8 and @vvbalaji-dgraph)

---

dgraph/cmd/zero/tablet.go, line 57 at r2 (raw file):

• Zero would tell G1 to move rest of the P's data (with T1<=ts<=T2) to G2 (Endpoint: Zero → G1)
• G2 acceps the data, but this time does not clean the current keys for P.
• G1 should tell Zero whetjer it succeeded or failed. (Endpoint G1 → Zero)

whetjer -> whether

[jarifibrahim]

Nice change! 💯