Fix protobuf stubtest errors

[AlexWaygood]

Fixes#8745.

I'm a little confused, as this PR is basically a revert of #8735. Stubtest appears to have run with the same environment for the two runs, so I'm not sure why the results are different:

• Run 1: https://github.com/python/typeshed/actions/runs/3049251326/jobs/4915126566
• Run 2: https://github.com/python/typeshed/actions/runs/3071453334/jobs/4962134427

We've had the same stubtest errors two nights in a row, however.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[Akuli]

The only difference between the runs I see is that the first has --shard-index 0, while the second has --shard-index 1. The --shard-index works like this:

iflen(args.dists) ==0:
dists=sorted((typeshed_dir/"stubs").iterdir())
...
fori, distinenumerate(dists):
ifi%args.num_shards!=args.shard_index:
continue

So we have added a project whose name starts with a letter before p, and now protobuf is stubtested along with a different set of projects than before. But the Ran with the following environment: section matches, so I don't know why the stubtest results would depend on what packages were stubtested previously.

[AlexWaygood]

The only difference between the runs I see is that the first has --shard-index 0, while the second has --shard-index 1. The --shard-index works like this:

A difference in how the daily test is being run would also be insufficient to explain the differences we're seeing in CI. We also need to explain the fact that stubtest passed on the PR run both in #8735 and in this PR. While we could speculate that there might be a bug in the script that somehow leads to different packages interfering with each other in the daily test, those concerns don't apply for stubtest in PR runs -- we can be confident that the package is being tested in a fairly isolated environment in a PR run.

[hauntsaninja]

Merging in case that makes the daily test stops failing. Note that we can use skip = true to make stubtest not check protobuf while we figure out what's causing the sometimes failures.

[JelleZijlstra]

At runtime google.protobuf.reflection.GeneratedProtocolMessageType.__init__ seems to be just type.__init__, so I don't know why we have the method in the stub at all.