Rename the vitess protos so that they don't collide with normal Vitess protos

[ryanpbrewster]

I believe this is the simplest solution to #155

For reference, here is the overview of that issue:
Pulling in both this Vitess fork and the normal Vitess repo simultaneously will cause protocol buffer namespace conflicts. This results in a runtime panic that looks like

panic: proto: file "vttime.proto" has a name conflict over vttime.Time
See https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict


goroutine 1 [running]:
google.golang.org/protobuf/reflect/protoregistry.glob..func1({0x1792700, 0xc000451580}, {0x1792700, 0xc000451580})
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/reflect/protoregistry/registry.go:54 +0x1f4
google.golang.org/protobuf/reflect/protoregistry.(*Files).RegisterFile.func1({0x17b5d08, 0xc0003ad860})
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/reflect/protoregistry/registry.go:152 +0x28f
google.golang.org/protobuf/reflect/protoregistry.rangeTopLevelDescriptors({0x17bb488, 0xc000321180}, 0xc00039d600)
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/reflect/protoregistry/registry.go:415 +0x154
google.golang.org/protobuf/reflect/protoregistry.(*Files).RegisterFile(0xc0001b2018, {0x17bb488, 0xc000321180})
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/reflect/protoregistry/registry.go:147 +0x745
google.golang.org/protobuf/internal/filedesc.Builder.Build({{0x15add42, 0x23}, {0x1b99e80, 0xc5, 0xc5}, 0x0, 0x2, 0x0, 0x0, {0x179b010, ...}, ...})
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/internal/filedesc/build.go:113 +0x1d6
google.golang.org/protobuf/internal/filetype.Builder.Build({{{0x15add42, 0x23}, {0x1b99e80, 0xc5, 0xc5}, 0x0, 0x2, 0x0, 0x0, {0x0, ...}, ...}, ...})
        /Users/ryanpbrewster/go/pkg/mod/google.golang.org/protobuf@v1.27.1/internal/filetype/build.go:139 +0x198
vitess.io/vitess/go/vt/proto/vttime.file_vttime_proto_init()
        /Users/ryanpbrewster/go/pkg/mod/vitess.io/vitess@v0.13.1/go/vt/proto/vttime/vttime.pb.go:239 +0x198
vitess.io/vitess/go/vt/proto/vttime.init.0()
        /Users/ryanpbrewster/go/pkg/mod/vitess.io/vitess@v0.13.1/go/vt/proto/vttime/vttime.pb.go:195 +0x17
FAIL    command-line-arguments  0.240s
FAIL

This PR ensures that the vendored vitess protos do not conflict with the originals (by moving them to a unique filepath starting with dolthub/)

[ryanpbrewster]

@zachmu is this the right repo to raise this issue + the fix? Or should I move the discussion to go-mysql-server?

[ryanpbrewster]

@fulghum I noticed you review another PR in this repo recently. Do you have any guidance on how to get a review for this PR?

[zachmu]

Hi Ryan, Sorry for the lack of response! We don't get many issues is this repo. We'll take a look at this on Tuesday and get back to you. Zach

…

On Sun, May 29, 2022, 16:02 Ryan Brewster ***@***.***> wrote: @fulghum <https://github.com/fulghum> I noticed you review another PR in this repo recently. Do you have any guidance on how to get a review for this PR? — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADT5FJOBMZO275SWVVVLA3VMPZQZANCNFSM5TOZ2I7Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zachmu]

I don't think we have any objection to this, but it's a breaking change up our entire stack to do this, so we need to give a little thought how we want to approach it.

[ryanpbrewster]

It may be less of an issue than you expect.

• I don't believe that this will change any of the generated protobuf Go code (except for modifying the proto descriptor slightly), so any code that passes around these protos should be unchanged.
• These protos are wire-compatible with the existing ones (as long as you aren't embedding them inside of google.protobuf.Any), so the upgrade should be smooth even if you have persisted data or inter-machine traffic.

If you can identify the breakages that you are worried about I'm happy to help smooth those out.

[reltuk]

@ryanpbrewster Thanks for the report and the suggestion. Some more changes to the proto files were necessary.

Would you take a look at #166 and let me know if it seems appropriate?

[ryanpbrewster]

That seems correct to me, and it definitely seems like it will resolve the protobuf namespace collision.

[ryanpbrewster]

Closing in favor of #166