IClientProxy should use `IEnumerable<object>`, not `params object[]` for args

[analogrelay]

The interface should take IEnumerable<object>, not a param-array for InvokeAsync. The current API is this:

SignalR/src/Microsoft.AspNetCore.SignalR/IClientProxy.cs

Line 16 in 79d8a9d

Task InvokeAsync(string method, params object[] args);

Param-arrays are a convenience for callers and should be done via Extension methods or something. If you have a list of arguments that aren't in the form of an array, but are enumerable, this API forces you to allocate an array and copy.

/cc @moozzyk @davidfowl @muratg consider this small fix for Alpha since it's a "public" API?

[analogrelay]

We use IReadOnlyList<object> in lifetime managers, if we want to use that here as well instead of IEnumerable that's fine. The issue here is we shouldn't be using object[], not that we should specifically be using IEnumerable :).

[davidfowl]

As long as the params arguments don't conflict with IEnumerable<object> (which I'm sure it does in some cases). This seems like a purity issue as nobody has ever complained about this when using SignalR.

[davidfowl]

I changed it to object[] args instead of IReadOnlyList<object>

[davidfowl]

9df8d2f
e17cdae

[analogrelay]

Wait what? That change seems ridiculous. It doesn’t do anything other than arbitrarily limit the number of arguments you can pass. You still force an array allocation. Using IReadOnlyList doesn’t conflict with having a params overload, I’ve done it plenty of times before.

[davidfowl]

@anurse I'm not sure what you mean. There's no limit, it's just making the common case easier (who has more than 10 arguments). We can change the object[] args to IReadOnlyList<object> but that doesn't avoid allocations.

These changes solve a bunch of things:

• You can pass arrays without doing weird things
• Cancellation tokens are last an optional

[analogrelay]

Ok, we're forcing the caller to create an array for more than 10 args, but that's probably OK.

Better would probably be to do a <T1, T2...> thing and create a struct that implements IReadOnlyList. Of course, someone down the line is probably still going to heap allocate for the arguments. Never mind, this would likely still box things somewhere.

[analogrelay]

Also, to be fair, I've had success with params and IReadOnlyList<T> where T is not object. Haven't tried with object, there may be quirks there.