Rename longrunning.operations* modules.

[lukesneeringer]

This commit renames the operations_grpc and operations_proto modules to operations_grpc_pb2 and operations_proto_pb2. This restores compatibility lost due to a change in the protobuf==3.2.0 Python package which requires some objects only to be created in modules that end in _pb2.

Notes:

• This pull request is entirely post hoc. :-) Due to the emergency nature of the change, I already pushed the package up to PyPI.
• As best as I can tell, this code is not actually automatically generated anymore (@geigerj said it used to be via. Packman, which is gone). We may or may not care about fixing that, since it does not really need to be updated often.

[theacodes]

Do any downstream users import google.longrunning.operations_grpc instead of google.longrunning.operations_pb2 or do all known downstream users import google.longrunning.operations_pb2?

[lukesneeringer]

All downstream users that I know of import google.longrunning.operations_pb2.

Ironically, I could solve the problem for both cases by just having operations_grpc and operations_proto exist and copy over all the exposed names from their _pb2 counterparts (which still would make the _pb2 counterparts do the final import and satisfy protobuf).

[theacodes]

Cool, thanks.

[geigerj]

FWIW gRPC codegen now automatically generates a try/except import block (grpc/grpc#8056), so once we regenerate googleapis-common-protos with the latest grpcio-tools, we should be able to remove this workaround altogether.

[lukesneeringer]

I have proven locally that 572db4b fixes googleapis/google-cloud-python#2989.

@geigerj @jonparrott Any issues with what I did there? If not, I will merge and then push 1.5.2 to PyPI (and then a re-test on Travis will fix Jon's PR).