StreamItem InvocationId cleanup

[DylanDmitri]

Previously, stream items were returned from the server in response to an invocation, and so carried an invocation id for routing purposes.

Now, stream items can be sent to the server, and are sorted based on stream id. Regardless of direction, all id values are stored under the InvocationId field on StreamItem. This is poor naming and rather misleading.

Possible solutions include:

• StreamItem has two fields, StreamId and InvocationId, only one of which can be filled at a time
• StreamItem has one field, RoutingId, which is used both ways. This breaks backwards compatibility.
• Make a new class StreamParameterItem that's identical to stream item but has a StreamId field instead.

None of these solutions feels very clean.

[analogrelay]

This one is going to take some extra thought so I'm increasing the cost for now. If it comes in under cost, that's even better :)

[DylanDmitri]

There's more thinking to do... the same base problem of InvocationId -vs- StreamId also applies to

• InvocationBindingFailureMessage (currently one class, probably should make a StreamItemBindingFailureMessage)
• CompletionMessage vs StreamCompleteMessage

Want to consider all of the cases when deciding on a good pattern.

[DylanDmitri]

Just making two classes for each. It seems the flattest/cleanest even if it's not concise/elegant.

[BrennanConroy]

@halter73 @mikaelm12
We are wanting to do a little redesign here. Idea is to move back to a single StreamItem message and CompletionMessage.

We have a bit of flexibility if we change the protocol version so we can have StreamItem with streamId in the new protocol and invocationId in the old protocol.

[muratg]

#4401

[BrennanConroy]

Done #4559

[davidfowl]

Thanks @DylanDmitri ! oh and @BrennanConroy 😉