Update generated protobufs.

[robshakir]

commit 26968c9a1b55134a879310986c2fa92c389127c3
Author: Rob Shakir <[email protected]>
Date:   Wed Nov 16 11:23:54 2022 -0800

    Update protobufs, bump healthz version.
    
     * (M) **/*.pb.go
       - Regenerate protobufs.
     * (M) heaslthz/healthz.proto
       - Update version to reflect new leaf addition in healthz in #106.

Update generated code and bump gnoi.Healthz version to 1.3.0 after leaf addition that was in #106.

[coveralls]

Pull Request Test Coverage Report for Build 3482471347

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 0.0%

---

Totals
Change from base Build 3446968859:	0.0%
Covered Lines:	0
Relevant Lines:	0

---

💛 - Coveralls

[earies]

Was going to open an issue on this but figured I'll just comment here as this sitting here pending is just one of the side effects I've seen post IDL modifications (in addition to issues not being addressed by anyone in this repo by the looks of it)

@robshakir @marcushines Why do generated stubs need to exist in this repo in the first place and if so then why just for golang? This is not a go specific project nor is there any client/server code exercising the stubs in this repo. Even if so, that should be a compile time option as I see it - no one should be using pre-generated stubs right?

Unless there is going to be actual implementation code (which you can then argue which languages), I think the pure IDL and documentation suffices here. If generated stubs are required to be uploaded after any IDL modification then how can you ensure all submitters are on the appropriate protoc versions to align here? Who is doing any validation of the stubs to make sure there was no modification before submission?

[robshakir]

There is existing client/server code that references the stubs that are generated in this repo, and it is the convention that we check these in alongside the protobuf in the place it is defined. There are projects that do depend on not generating the .pb.go at compile time -- most open source Go projects do this (looks like there are >2M .pb.go files on GitHub)

We can extend this and add other languages based on the demand for it (e.g., gNMI has the python bindings checked in), please open a PR if you would like other languages. Equally, we have checks in other repos that does ensure that the protos have been updated, which can be enabled here.

I don't quite understand the objection here. What is the downside other than we don't have the CI set up to ensure that there isn't drift?

[marcushines]

i believe the benefits of having an easy go mod install solution for these protos outweight any negatives
Also if other languages request the same generation logic we could add those libraries

[hellt]

I am coming from the camp where we salute generated stubs provided upstream, as this allows us to rely on the commonly generated stubs and import them in the client/server implementation, knowing that others will use the same product of generation.