mvcc: allow clients to assign watcher IDs

[gyuho]

Cherry-pick #8662.
Fix #7036.

/cc @connor4312

[xiang90]

let us wait for the 3.3 rc release. this should go into 3.4 branch not 3.3 release branch.

[gyuho]

@xiang90 Sounds good. Will merge after 3.3 release branch cut.

[xiang90]

@gyuho let us get this merged into master?

[gyuho]

@xiang90 Yeah let me rebase first and see if test passes.
Previously, some watch tests were failing.

UPDATE: investigating https://semaphoreci.com/coreos/etcd/branches/pull-request-9015/builds/3

--- FAIL: TestCtlV3AuthAndWatch (15.19s)
	testutil.go:55: goroutine 5054 [running]:
		github.com/coreos/etcd/pkg/testutil.FatalStack(0xc420012690, 0xc420014e00, 0x18)
			/go/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/pkg/testutil/testutil.go:54 +0x74
		github.com/coreos/etcd/e2e.testCtl(0xc420012690, 0xd2c7d0, 0x0, 0x0, 0x0)
			/go/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/e2e/ctl_v3_test.go:179 +0x4ac
		github.com/coreos/etcd/e2e.TestCtlV3AuthAndWatch(0xc420012690)
			/go/src/github.com/coreos/etcd/gopath/src/github.com/coreos/etcd/e2e/ctl_v3_auth_test.go:42 +0x52
		testing.tRunner(0xc420012690, 0xd2c268)
			/usr/local/go/src/testing/testing.go:746 +0xd0
		created by testing.(*T).Run

This case fails

		{ // watch 1 key, should not be successful
			[]kv{},
			[]string{"key5", "--rev", "1"},
			[]kvExec{},
			false,
		},

To reproduce

ETCDCTL_API=3 ./bin/etcdctl user add root --interactive=false
root

ETCDCTL_API=3 ./bin/etcdctl user grant-role root root
ETCDCTL_API=3 ./bin/etcdctl auth enable

ETCDCTL_API=3 ./bin/etcdctl --user=root:root user add abc --interactive=false
def

ETCDCTL_API=3 ./bin/etcdctl --user=root:root role add test-role
ETCDCTL_API=3 ./bin/etcdctl --user=root:root user grant-role abc test-role
ETCDCTL_API=3 ./bin/etcdctl --user=root:root role grant-permission test-role readwrite foo

ETCDCTL_API=3 ./bin/etcdctl --user=root:root role grant-permission test-role readwrite key key4

ETCDCTL_API=3 ./bin/etcdctl --user=abc:def watch key5 --rev 1

<<COMMENT
expect
Error: watch is canceled by the server
COMMENT

[gyuho]

@xiang90 This PR breaks backward compatibility if we want to returning the original ID from watch create request.

<= v3.3: canceled watch request response always resp.WatchId == -1
>= v3.4: canceled watch request response may have watch ID.

So, the way to check cancellation changes. We could keep returning -1 as watch ID on cancellation, but clients won't be able to know which one is canceled...

[gyuho]

Replaced by #9065.