There is at least one well-known proto file (plugin.proto) with comments
that include variable-like strings that are not actual variables. This
leads to DFATAL log statements that clutter the output and don't provide
any benefit.
Now the grpc_2_0 flag is no longer required for the only-generate-code-
elements-in-_pb2_grpc.py-files behavior and the grpc_1_0 flag is
required for the add-generated-gRPC-using-code-elements-to-_pb2.py-
files behavior.
We'll soon be flipping the default behavior of gRPC Python Protoc
Plug-In to the later-than-gRPC-1.0 "code elements only in a
separate _pb2_grpc.py file and no Beta-API-using generated code
elements" behavior; this flag will be the supported (supported for a
while, though not exactly sure how long) means of using the older
"also put gRPC-using code elements in the generated _pb2.py file"
behavior that has been in place since gRPC 1.0.
For Flatbuffers compatibility.
From what I can tell, File::additional_headers is not used by gRPC
itself or its default protobuf implementation; it was added for
Flatbuffers support (it just returns "" for protobuf).
In the Flatbuffer case, the generated header contains references to
Flatbuffer gRPC glue code which is in a header in additional_headers.
Prior to this patch, this meant that the generated .h file could not
be included unless this glue file was included first.
Because the protobuf implementation of additional_headers returns
an empty string, I think this change should be safe to do and not
have unintentional consequences.