Subject protocol updated in beta5 - replaySubject doesn't currently conform about entwine

[tcldr]

Thanks @heckj ! Have added a temporary fix. Will have a more in depth look when I get a chance. Haven't worked out how it's supposed to handle back pressure yet.

[tcldr]

As far as I can tell, PassthroughSubject sends the subscription it receives via send(subscription:) an unlimited demand and moves along. I've added some tests to master to confirm this behaviour
in ReplaySubject against a control (PassthroughSubject).

I'm interested to see what functionality this api is supposed to enable though, as theoretically a subscription sent via a subject would be shared amongst all its subscribers. So how would these subscribers safely attenuate demand via a shared subscriber? The greediest subscriber will set the pace for all other subscribers.

Potentially it's a glimpse of some testing utilities Apple are assembling – a way of gathering the messages set to a subscription by a downstream subscriber. Maybe thats's what this new Record type is all about.

[heckj]

completely hypothesizing here, but I suspect it’s meant specifically for the variable demand use case. Specifically where a subscriber is taking in data at a specific rate in response to back pressure and wants to vary that rate over the lifetime of available data from the publisher.