Provide .proto files with Editions Syntax and .class files compatible with protobuf-java v4

[joh-ivu]

Is your feature request related to a problem? Please describe.
It is currently not possible to fully use Protobuf Editions in most of my company's protobuf definitions, because the dependency com.google.api.grpc:proto-google-common-protos is not provided in a Protobuf 2023 version. We depend on types like google.type.Date almost everywhere.

Transcompiling our own .proto-Files leads to Java code that is dependent on com.google.protobuf:protobuf-java in v4, but the precompiled classes in com.google.api.grpc:proto-google-common-protos require v3 and there are binary incompatible changes between the two. It is therefore not possible to use com.google.api.grpc:proto-google-common-protos as before.

Describe the solution you'd like
A new version of the library is published that contains .proto files in Protobuf 2023 syntax and .class files compatible with com.google.protobuf:protobuf-java v4.x.y

Describe alternatives you've considered
If no new version of the library is provided by google itself, we'd have to resort to distributing our own company-internal fork of the library that contains the updated .proto files (optional) and .class files precompiled with protoc v4.

Since the Java-Runtime v3 reaches end of support within a year and our company (and I imagine other companies as well) cannot switch all or protobuf over night, this cannot remain unresolved for long.

[joh-ivu]

I am under the impression that proto3-Syntax will still compile for a while, even with newer versions of protoc. So that's not what I'm most worried about. I'm more worried about the protobuf-java dependency so if it's possible to release the same protos, but with .class-files that depend on protobuf-java v4, then that would be fine for me as well.

I'm not sure yet what new features we will use in our company. Probably the feature to locally declare an enum-type as open / closed. That always causes a little bit of confusion among new colleagues. Other than that we'd be fine using proto3 for a while longer, but without an up-to-date runtime that's not the preferred option for us.