GH-41347: [FlightRPC][C#] Allow hosting flight server in pre-Kestrel .net versions

[qed-]

Rationale for this change

With the existing structure it is not possible to create a flight RPC service as a regular GRPC service, outside of AspNet.Core/Kestrel.

This can be supported by changing the protection level of the generated classes and FlightServiceImplementation.cs

What changes are included in this PR?

Change protection level from internal to public for generated protocol files and FlightServiceImplementation.cs

Are these changes tested?

Confirmed that classes are public in the built assembly.

Are there any user-facing changes?

Generated protocol classes will become visible to end users.

• GitHub Issue: [C#][Flight] Add support for non-Kestrel Flight server #41347

[github-actions]

⚠️ GitHub issue #41347 has been automatically assigned in GitHub to PR creator.

[CurtHagenlocher]

It's a bit unfortunate that we have to expose so many internals to make this work; it creates "upgrade risk" for anyone who happens to take a dependency on the generated classes. Out of curiosity, what's the server or servers you're interested in? Are they likely of wider interest? Could we ship that support as a separate project from this codebase?

Otherwise, I think FlightServerImplementation should be moved to the "Server" namespace and directory as it's clearly no longer "Internal".

[qed-]

Thanks for your comments. My use case is to run a Flight GRPC server on .Net framework (due to it depending on legacy assemblies that don't work with .net core).

I've modified the PR to move the namespace as you suggested.

The other option would be to create a public class that implements code similar to the below, happy to do it this way if you think this is a better option.

using Apache.Arrow.Flight.Protocol;
using Apache.Arrow.Flight.Server;

var flightServer = new FlightServerImpl();
var server = new Server
{
    Services = {  FlightService.BindService(new FlightServerImplementation(flightServer)) },
    Ports =  { new ServerPort("0.0.0.0", 5001, ServerCredentials.Insecure) }   }
};
server.Start();

[qed-]

Hi @CurtHagenlocher, please let me know if you'd like further changes to this PR.

[qed-]

hi @CurtHagenlocher - any feedback on this? Thanks.

[CurtHagenlocher]

I'm very sorry for the delay, @qed; I'd meant to take another look at this before the fork for the next release, but we've now run out of time. Can you say a little more about the other option? What class exactly is "Server" here?

[qed-]

Hi @CurtHagenlocher, no worries.

Server is this class https://grpc.github.io/grpc/csharp/api/Grpc.Core.Server.html

We are using this to run the server on HTTP.sys, due to Kestrel not being available in .Net framework.

[CurtHagenlocher]

Okay, thanks! What if we were to have a separate build target which references Desktop framework and contains a package reference to that older gRPC framework and the code you need to be able to use it? That way, the newer package doesn't pick up a conflicting and unneeded dependency.

[qed-]

Yes I'd be happy with that approach.

[qed-]

@CurtHagenlocher changed as suggested, let me know if you'd like any further changes.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit cf010cd.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 31 possible false positives for unstable benchmarks that are known to sometimes produce them.