regenerate all protobuf messages

[Aaronontheweb]

Changes

While analyzing a detailed ETW breakdown of #6078, saw that most of the CPU time being gobbled up was actually during the AckAndEnvelopeContainer.Parser.ParseFrom operation. Decided to try re-genning the Protobuf C# objects with the latest version of the .proto compiler to see if there were any improvements.

Checklist

For significant changes, please ensure that the following have been completed (delete if not relevant):

• This change follows the Akka.NET API Compatibility Guidelines.
• This change follows the Akka.NET Wire Compatibility Guidelines.
• I have reviewed my own pull request.

Latest dev Benchmarks

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1889 (21H2)
AMD Ryzen 7 1700, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.201
  [Host]     : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT
  DefaultJob : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Allocated
WritePayloadPdu	2,533.8 ns	13.58 ns	12.04 ns	0.4219	1,768 B
DecodePayloadPdu	3,040.1 ns	10.46 ns	9.27 ns	0.4375	1,832 B
DecodePduOnly	229.7 ns	2.04 ns	1.59 ns	0.1145	480 B
DecodeMessageOnly	2,383.1 ns	8.66 ns	6.76 ns	0.2813	1,184 B
DeserializePayloadOnly	231.3 ns	1.10 ns	0.92 ns	0.0398	168 B

This PR's Benchmarks

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1889 (21H2)
AMD Ryzen 7 1700, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.201
  [Host]     : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT
  DefaultJob : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
WritePayloadPdu	2,424.5 ns	14.41 ns	12.78 ns	0.4375	-	1,832 B
DecodePayloadPdu	2,761.7 ns	11.57 ns	10.82 ns	0.4500	0.0031	1,888 B
DecodePduOnly	275.8 ns	2.03 ns	1.58 ns	0.1164	0.0004	488 B
DecodeMessageOnly	1,992.0 ns	15.65 ns	13.87 ns	0.2938	-	1,232 B
DeserializePayloadOnly	227.2 ns	1.10 ns	0.98 ns	0.0398	-	168 B

[Aaronontheweb]

Looks like memory allocations are up but latency is down on this PR. Going to re-run this PR's benchmarks a few times.

[Aaronontheweb]

@Arkatufus idea - I wonder, how often does the Grpc.Tools Protobuf compilation support built into newer .NET projects recompile the generated messages? Is that something we'd still have to do manually every now and again?

[Aaronontheweb]

Run 2

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1889 (21H2)
AMD Ryzen 7 1700, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.201
  [Host]     : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT
  DefaultJob : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
WritePayloadPdu	2,427.0 ns	19.85 ns	15.49 ns	0.4375	-	1,832 B
DecodePayloadPdu	2,708.3 ns	6.73 ns	5.62 ns	0.4469	-	1,880 B
DecodePduOnly	266.1 ns	4.20 ns	3.72 ns	0.1164	0.0004	488 B
DecodeMessageOnly	1,989.4 ns	9.44 ns	8.83 ns	0.2938	-	1,232 B
DeserializePayloadOnly	232.9 ns	1.42 ns	1.26 ns	0.0398	-	168 B

Run 3

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1889 (21H2)
AMD Ryzen 7 1700, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.201
  [Host]     : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT
  DefaultJob : .NET 6.0.3 (6.0.322.12309), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
WritePayloadPdu	2,393.3 ns	13.20 ns	11.03 ns	0.4375	-	1,832 B
DecodePayloadPdu	2,723.2 ns	17.59 ns	14.69 ns	0.4500	-	1,888 B
DecodePduOnly	277.8 ns	2.07 ns	1.83 ns	0.1164	0.0004	488 B
DecodeMessageOnly	2,016.2 ns	8.58 ns	8.02 ns	0.2938	-	1,232 B
DeserializePayloadOnly	233.4 ns	2.89 ns	2.70 ns	0.0398	-	168 B

[Arkatufus]

LGTM