Use grpc-dotnet instead of grpc

[Zaid-Ajaj]

Description

This PR addresses the following issues:

• Update grpc to grpc-dotnet #8476
• Dotnet 6 issues on m1 & m1max cpus - running pulumi up fails #8447

First of all, replaces Grpc package which is now in maintenance mode (until 2022 May) with grpc-dotnet, specifically using the Grpc.Net.Client package instead.

We are still using the Grpc.Tools package as the main way to generate C# types and clients from our proto files. Though updated this one from 2.37.0 to 2.44.0 (latest)

Using a local copy of updated Pulumi nuget package and a local, updated version of Pulumi.Aws package, I've managed to successfully deploy resources to AWS using pulumi up and a console application also running on net6.0 target framework on my M1 machine.

Checklist

• I have added tests that prove my fix is effective or that my feature works

• I have updated the CHANGELOG-PENDING file with my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

[Frassle]

This isn't the old package reference still being used via the Tools dep is it?

[Zaid-Ajaj]

I think so, i will remove it

[justinvp]

Why is _engineChannel static? Should _engineChannelLock be static too? (Same questions for GrpcMonitor below).

[Zaid-Ajaj]

@justinvp According to the docs, creating a GrpcChannel is expensive whereas creating the gRPC client that uses the channel is not: hence I was keeping a single instance of the channel to be used across client instances to avoid recreating the channels every time.

As for _engineChannelLock it doesn't need to be static since it is only used for locking.

The lock however is no longer needed! I refactored the code to use a (concurrent) dictionary to keep track of the channels created by different Engine and Monitor addresses. This dictionary is thread-safe and doesn't need special locking

[Frassle]

Suggested change

	// According to the docs, creating GrpcChannels is expensive so we keep track of a bunch of them here
	// According to the docs(https://docs.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-6.0#reuse-grpc-channels), creating GrpcChannels is expensive so we keep track of a bunch of them here

[Zaid-Ajaj]

Added links to the docs, thanks!

[Frassle]

Wonder if we should have a "GrpcPool" class to share between GrpcEngine and GrpcMonitor.

[Zaid-Ajaj]

i think for this use case it is simple enough to keep it as imo

[justinvp]

Nit: readonly

[justinvp]

Should we use GetOrAdd?

var engineChannel = _engineChannels.GetOrAdd(engineAddress, address =>
{
    // maxRpcMessageSize raises the gRPC Max Message size from `4194304` (4mb) to `419430400` (400mb)
    var maxRpcMessageSize = 400 * 1024 * 1024;

    // Allow for insecure HTTP/2 transport (only needed for netcoreapp3.x)
    // https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0#call-insecure-grpc-services-with-net-core-client
    AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
    // Inititialize the engine channel once for this address
    return GrpcChannel.ForAddress(new Uri($"http://{address}"), new GrpcChannelOptions
    {
        MaxReceiveMessageSize = maxRpcMessageSize,
        MaxSendMessageSize = maxRpcMessageSize,
        Credentials = Grpc.Core.ChannelCredentials.Insecure,
    });
});

_engine = new Engine.EngineClient(engineChannel);

[Zaid-Ajaj]

That would be another way of implementing it. GetOrAdd does exactly the same as the above: checks if it exists and return it or if the key does not exist, adds to the dictionary. Do you want me to update the code with GetOrAdd instead?