[RFC] Remove UnifiedMessages reflection usage

[affederaffe]

This PR tries to remove the last directly existing reflection usage in SteamUnifiedMessages.
The protobuf code generator was updated instead to directly handle the messaging.
Obviously this is a breaking change, but, at least in my opinion, necessary in order to fully remove reflection.

[xPaw]

I like the idea. If you enable the trimming warnings, what warnings are reported? In particular handling of incoming messages.

Do note that protobuf.net is heavily reflection based, so that doesn't help us with AOT/trimming atm.

[xPaw]

I'd remove {SERVICE_NAME} and just make it a const string.

Also can be simplified by using => instead of { return ... }

[affederaffe]

I like the idea. If you enable the trimming warnings, what warnings are reported? In particular handling of incoming messages.

Do note that protobuf.net is heavily reflection based, so that doesn't help us with AOT/trimming atm.

There seem to be no more trimming warnings aside from protobuf.net usage. I'll try to see how to avoid these too soon ™️

[xPaw]

@yaakov-h was also looking at that, and arrived at the conclusion that switching to google.protobuf is probably the way to go.

[xPaw]

I don't however like calling CanHandleMsg for every single interface, maybe registration and a dictionary lookup would work better.

See 807fa51 for previous attempt at that.

[affederaffe]

I don't however like calling CanHandleMsg for every single interface, maybe registration and a dictionary lookup would work better.

See 807fa51 for previous attempt at that.

It's not really every interface, only for currently created services (until they are disposed that is).
A dictionary could actually be worse for memory usage I imagine, but that'd need testing

[xPaw]

Right I see it only goes through the registered services. But it calls CanHandleMsg for every service so it does the parsing for every one of these.

The handlers list could be a dictionary of <service name, handler>, so that you can parse the method name, and directly check if a handler is registered for a particular service.

[yaakov-h]

This is a very different approach to the one I was looking at, and I do like it.

Keep in mind that consumers should be able to generate and run additional services (e.g. from updated protobufs) so some of those internal methods would need to be public.

Regarding the discussion above, perhaps each service should expose its name as a public property, then we can parse the service name once and invoke any matching handlers?

However, yes, for full trimming support and AOT we will almost certainly need to switch to Google.Protobuf. I haven't spiked AOT w/ Google just yet, but even manually hand-writing serializers and deserializers with protobuf-net.Core triggered trim and AOT warnings because it is annoyingly dependent on dynamic coding APIs.

[xPaw]

perhaps each service should expose its name as a public property

Could add service name to UnifiedService, and then have HandleMsg( method, version, packet ) and then only call HandleMsg if the service name matches.

[xPaw]

FYI this PR needs to rebase the protobufs submodule because its using an older commit.