There is a behavioral discrepency in
`DescriptorPool.FindFileContainingSymbol` between the two
implementations of the protobuf python library (one of which is purely
python, and the other utilizes a python extension library written in
C++).

protobuf on PyPI is distributed via various prebuilt wheels, and our CI
setup fetches the relevant one for each platform.  Our Linux instances
end up fetching a pre-compiled C++ version of the library, whereas our
Mac and Windows builders automatically get the pure python version.
This test fails (and our reflection implementation itself) succeeds with
the C++ implementation but fails with the pure python version.

The test will be temporarily disabled pending a fix for
https://github.com/google/protobuf/issues/2882

While not strictly required by the protocol,
it will make testing easier.

Fix and un-skip the test for _file_containing_extension
in python reflection service to refer to the correct proto
and expect the right object to be returned. Enable it too.

Just the API and a bare-bone implementation

If the server is already serving max requests, return RESOURCE_EXHAUSTED

Skip SameSeparateTest, SameCommonTest, SplitCommonTest, and
SplitSeparateTest if the interpreter is PyPy.

In _server.py start_server_batch_result is removed because
start_server_batch can only ever fail as a result of a programming
defect in gRPC Python and not the application. This differs from some
analogous-appearing points in _channel.py where the result of
start_client_batch is checked because at those points it is possible
for a failure to indicate a programming defect on the part of the
application.