Add features files to the set of standard imports

[jhump]

The "standard imports" (made available to compile operations using protocompile.WithStandardImports) are files that would be included with protoc, if a user were instead compiling with protoc.

As of v26.1, protoc now includes two new files: "goole/protobuf/cpp_features.proto" and "google/protobuf/java_features.proto". But these are not generated to Go code into packages in the Protobuf runtime, unlike all of the other well-known types. So, for these, we embed binary-encoded file descriptors.

Notably protoc does not include "google/protobuf/go_features.proto". However, that file is part of the Go Protobuf runtime, with its generated code being available via the google.golang.org/protobuf/types/gofeaturespb package. So we also make that file available via protocompile.WithStandardImports (even though protoc doesn't include it).

[emcfarlane]

How would we go about updating the protoset files and would other languages be included as they are added?

[jhump]

How would we go about updating the protoset files and would other languages be included as they are added?

To the first part: that's part of the make generate target. So updating to a new protoc (by editing the protoc version file) will automatically pull everything in and update everything (and check that it's updated in CI).

To the second: if they add new files to the core Protobuf SDK (that now includes cpp_features.proto and java_features.proto, then we'd want to add them here, too, just to mimic protoc's ability to provide these files without users having to explicitly provide them elsewhere. The Protobuf team says they would only include such files with the protoc download for languages whose code generation is built directly into protoc. (I chose to add go_features.proto here, even though it does not fall into that camp just because it is trivially available via the Protobuf Go runtime, and people using a Go library to process protos might be more likely to be using the Go features.)