Migrate etcd backend to APIv3 client

[abronan]

We should migrate the etcd backend to use the new APIv3 client using grpc.

This would solve #16 and #20 and smooth the library usage especially on the key handling.

Only problem for now is the Lock call that is not yet supported by the new client, so we might have to wait for that first or use our own implementation of Lock.

[ringods]

@abronan if I would provide a pull request for this, should this replace the current etcd v2 setup, or should I provide a separate etcd3 backend?

[abronan]

Hi @ringods, thank you for tackling this. I think this should be a separate etcd3 backend as I'm not sure that backward compatibility is maintained (the distributed lock implementation might change between v2 and v3 for example).

Although before putting in the work I would recommend getting a status from the maintainers of the repository. I'm no longer maintaining it and it does not seem to be actively maintained anymore.

I thought about forking as many people may still rely on it but I'm not sure I can invest time maintaining a fork for now.

[ringods]

Call to @aluzzardi, @sanimej and @vieux to shed some light on the activity status of docker/libkv and docker/leadership. Should I contribute etcd3 support here, or do it directly in the traefic repository to have this issue fixed?

[ringods]

I found work in progress on etcd3 in this fork:
https://github.com/dqminh/libkv/tree/etcdv3/store/etcdv3
@dqminh, you need a hand finishing it?

[vcastellm]

@ringods I'm also interested in the v3 support, ping me if more help is needed.