Bump github.com/jhump/protoreflect from 1.16.0 to 1.17.0

[dependabot]

Bumps github.com/jhump/protoreflect from 1.16.0 to 1.17.0.

Release notes

Sourced from github.com/jhump/protoreflect's releases.

v1.17.0

This release deprecates some packages that have newer alternatives in the Protobuf runtime. It also includes some small additions to the grpcreflect and desc/sourceinfo packages. The rest of the changes are bug fixes.

"github.com/jhump/protoreflect/desc"

Changes:

• This package is now deprecated. Though use of this package is still needed in order to use a handful of other packages in this repo, many usages should instead prefer the "google.golang.org/protobuf/reflect/protoreflect" package in the Protobuf runtime. In a v2 of this repo, this package will no longer be present.
• A performance improvement was contributed that speeds up the MessageDescriptor.FindFieldByName method.

"github.com/jhump/protoreflect/desc/protoparse"

Changes and bugfixes:

• This package is now deprecated. Most usages should instead prefer the "github.com/bufbuild/protocompile" package. There are some behavioral differences that we hope to address with additional API and enhancements to protocompile. But the protoparse package here is just a veneer on top of protocompile and we plan to do as little maintenance as possible here. In a v2 of this repo, this package will no longer be present.
• The protocompile dependency has been updated to use a more recent version of that package. This addresses potential panics when calling Parser.ParseButDontLink.

"github.com/jhump/protoreflect/desc/sourceinfo"

Changes and bugfixes:

• A possible panic when calling sourceinfo.GlobalFiles.FindDescriptorByName has been fixed.
• Descriptors returned from the sourceinfo.GlobalFiles registry or from the various Wrap* functions could induce panics in user code if querying for non-existent elements. For example, calling messageDescriptor.Fields().ByNumber(123) could return a typed-nil value on failure, instead of a nil interface. This would result in nil-dereference panics if methods were called on this later. These have been fixed.
• Descriptors returned from the sourceinfo.GlobalFiles registry and from the various Wrap* functions had concrete types defined in this package, not in the Protobuf runtime. But the protoreflect.Descriptor interface has a "do not implement" marker, indicating that concrete types implementing the interface should not be implemented outside of that module. To avoid future issues with the Protobuf runtime, there are no more implementations in this repo. Instead of wrapping other descriptor implementations (via embedding, and then overriding some methods), this package now builds new descriptors, using the protodesc package in the Protobuf runtime module.
• The various Wrap* functions are now deprecated. The name is no longer accurate since they no longer return wrapper values. Also the new implementation, which builds new descriptors, can fail (though unlikely), but the existing signature of these functions did not allow for returning an error. So these functions could possibly panic in the face of malformed input descriptors. Users should use the new AddSourceInfoTo* versions of these functions instead.

Additions:

• Adds AddSourceInfoTo* functions to replace the Wrap* functions. These functions augment the input descriptors by adding source code information to them.

"github.com/jhump/protoreflect/dynamic"

Changes:

• This package is now deprecated. Most usages should instead prefer the "google.golang.org/protobuf/types/dynamicpb" package in the Protobuf runtime. In a v2 of this repo, this package will no longer be present.

"github.com/jhump/protoreflect/grpcreflect"

Additions:

• Adds a new NewClientV1 function to return a client that uses v1 of the server reflection service. This fills the gap in the existing factory functions, NewClientV1Alpha and NewClientAuto.
• Adds a new AllowFallbackResolver method to the *grpcreflect.Client type. This allows the client to be configured with an alternate resolver that can be used as a backup when trying to satisfy dependencies, for cases where the remote server is non-authoritative and unable to provide all of them.

Commits

• 06e5c08 Update desc/sourceinfo to not wrap descriptors (#622)
• 645b9dd Update protocompile, which fixes possible panic in ParseButDontLink (#621)
• 9b68e7b Update styling of callouts in README; add info about trying out v2
• 9fdd942 Allow grpcreflect to fall back to provided resolvers (#614)
• baac311 update deps; reconcile couple of tests with latest protocompile (#613)
• bed9136 desc/sourceinfo: fix panic when descriptor not found (#612)
• cb1d268 perf: use concatenation to compute qualified name in MessageDescriptor.FindFi...
• 1ba1524 Add deprecation notices to the packages in this repo that have newer replacem...
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[oleiade]

✋🏻 We need to adapt the imports, as per the release notes before merging ✋🏻

[oleiade]

I've invested a couple hours of time looking into the deprecations brought by this package, and I must admit I'm really out of my depth, and I honestly have no clue how to go about it still. I think it would take me a sizeable amount of time to be able to make this change with confidence as I just don't have enough context on protobuf and our grpc at the moment; and I frankly don't have the capacity to invest in going any further myself at the moment.

Is this something you'd have the capacity and interest to look into @olegbespalov ?

Otherwise, the bottom line is, 1.17.0 (the updated version) appears to be the last of their version 1 scope. So as long as we don't move to 2.0 .0 (in alpha at the moment) it should be somewhat okay to either not upgrade from 1.16.0 to 1.17.0, or ignore the deprecation warnings in the meatime, if we don't have the capacity to pursue it.

cc @mstoykov

[mstoykov]

I think it is okay if we skip this for v0.55.0 and try to get it in the next one after some more investigation.

If we want to get this done now I will also recommend adding just //nolint clauses and opening an issue. This likely is better either way as it will let us have separate commtis for the transition - potentially testing if it works okay.

[olegbespalov]

Is this something you'd have the capacity and interest to look into @olegbespalov ?

Hey @oleiade, no, I don't have the capacity for doing that.

Frankly, I believe that this should be handled by another team member. I don't want us to create a knowledge silo around things related to gRPC (like any other specific topic). And seems like this issue is a good opportunity to acquire knowledge in that domain since it remains in the core, and occasionally, we need to do work in that area.

I do agree that there is no urgency in doing that right now, so let's skip it now and allocate resources in future cycles.

[oleiade]

Fair enough 👍🏻

I agree with your assessment @olegbespalov, I know I would have liked to get more comfortable around that module (I tried), I just don't have the capacity right now.

Thus, I'll update to v1.17.0, add //nolint statements and open an issue then 🙇🏻

[oleiade]

I opened #4035 , and added nolint statements to make this PR green. Ready to merge 🚀

cc @mstoykov