C#: Suppress CS8981 in generated source

[JamesNK]

Fixes grpc/grpc#29672

This is option 2 (see linked issue). It suppresses the new warning in the generated source code. It's the simplest change and I think it's unlikely that any of the namespace aliases would turn into keywords.

@jtattermusch @jskeet

[jskeet]

This seems reasonable to me. It's an unfortunate warning to be on by default IMO (and particularly as it refers to the alias as a type name, when it's not) but suppressing it seems reasonable. Will wait for @jtattermusch's input.

We should regenerate all the code in the csharp directory as well - I'm happy to do that after this PR is in, or it could be a second commit in this PR.

[JamesNK]

We should regenerate all the code in the csharp directory as well - I'm happy to do that after this PR is in, or it could be a second commit in this PR.

A follow-up PR would be great. I've rebuilt my machine since I last updated the C++ bits in this repo, and I don't have it setup anymore.

I see an RC for the next release has recently been cut - https://github.com/protocolbuffers/protobuf/releases/tag/v21.0-rc1. What do you think about putting this change into 21? Either RC2, or a patch release for it?

This fix isn't urgent yet because .NET 7 is only in preview, but anyone who downloads it and compiles generated Protobuf or gRPC code will get compiler warnings, and that'll break those with WarningsAsErrors enable. They'll need to update their csproj to suppress this error.

[jskeet]

I see an RC for the next release has recently been cut - https://github.com/protocolbuffers/protobuf/releases/tag/v21.0-rc1. What do you think about putting this change into 21? Either RC2, or a patch release for it?

I don't know enough about the protobuf release process to know whether that's feasible/desirable - I'll follow up internally.

Fundamentally, I think it's pretty reasonable for folks using preview builds to have to take some action when a new warning is introduced.

[jtattermusch]

LGTM, the proposed solution looks good.

I'd say let's add a commit to this PR so that it has both the generator code and the regenerated sources.
Note that other maintainers can push commits to this PR.

@jskeet do you want to push the regenerated protos to this PR?

[jskeet]

@jtattermusch: I'm fine with that as a plan - but I can't do it myself as I currently don't have a working Google machine. (Long story.) Are you happy to pull, build, regenerate and add the commit yourself?

[jtattermusch]

@jtattermusch: I'm fine with that as a plan - but I can't do it myself as I currently don't have a working Google machine. (Long story.) Are you happy to pull, build, regenerate and add the commit yourself?

Regenerated C# protos pushed in a separate commit.

[jskeet]

Thanks @jtattermusch - will merge when the Kokoro build has completed.

[jskeet]

The MacOS Ruby Kokoro build seems to have actually completed successfully (just not reported back) so I'll merge now.

[jtattermusch]

For the gRPC codegen plugin update, also see grpc/grpc#29708

[jtattermusch]

Should be backport this to one of the existing release branches?
(see grpc/grpc#29708 (comment))
I don't think this change by itself requires a protobuf patch release, but if we're already planning a patch release for protobuf, we might as well include this change.
I'm unfortunately not fully up to date on the recent protobuf versioning change, so I'm not sure whether we would backport to https://github.com/protocolbuffers/protobuf/releases/tag/v21.0-rc1 or to https://github.com/protocolbuffers/protobuf/releases/tag/v3.20.1.