Add support for DI in Hub methods

[BrennanConroy]

Fixes #16686

The issue talks about having a [FromServices] attribute, that isn't addressed in the current form of this PR.
Using IFromServiceMetadata like we do for Minimal APIs to check if a parameter should be resolved from a service. This makes the feature opt-in and less likely for us to accidentally mess something up.

Source generator wont be able to do anything special about hub methods with services, but that might just be something we don't care about and developers should design their interfaces with that in mind.

Currently using a mask (ulong) to store indices for service positions in Hub methods which limits hub methods to 64 arguments, I think this is fine though 😄

API

public class HubOptions
{
+    public bool DisableImplicitFromServiceParameters { get; set; }
}

[davidfowl]

Currently using a mask (int) to store indices for service positions in Hub methods which limits hub methods to 32 arguments, I think this is fine though 😄

This is jank and it should work for any number of arguments even though 32 is insane. 64? 😄

[BrennanConroy]

This is jank and it should work for any number of arguments even though 32 is insane. 64?

Changing the field to long would allow 64, I'd prefer not going bigger because then we'll need to allocate/lazy-alloc and have another field.

[halter73]

This is jank and it should work for any number of arguments even though 32 is insane. 64?

Changing the field to long would allow 64, I'd prefer not going bigger because then we'll need to allocate/lazy-alloc and have another field.

Sounds reasonable. I don't think allocating a bool[] once per hub method would be that bad, but it also doesn't feel that valuable to support a service argument after the 64th position. The startup error message is clear enough.

[halter73]

I think we should infer service parameters by default. I'd be tempted to remove this option altogether. How many service types are also serializable? I see wanting an option to opt-out though since there isn't another escape hatch I can see if you happen to have an argument type registered as a service.

[BrennanConroy]

I see wanting an option to opt-out though since there isn't another escape hatch I can see if you happen to have an argument type registered as a service.

This is my main concern, which is why I switched the whole PR to using IFromServiceMetadata and then having an opt-in for inferring.

[davidfowl]

Lets do an opt-out then.

[BrennanConroy]

I'm going to leave as opt-in for now, we can discuss in chat and/or API review

[ghost]

Thank you for your API proposal. I'm removing the api-ready-for-review label. API Proposals should be submitted for review through Issues based on this template.

[ghost]

Thank you for your API proposal. I'm removing the api-ready-for-review label. API Proposals should be submitted for review through Issues based on this template.

[BrennanConroy]

@davidfowl @halter73 This should be ready for final review, updated to be opt out and use the API approved name.