A while back (v37?), the salesforce streaming API started requiring a replayId.
Prior to this, the behavior was equivalent to -1 (new events that are broadcast after the client subscribes). If we default `defaultReplayId` to -1, it provides a sensible default for new projects, and is backwards compatible with existing projects that are on old versions of the streaming API.
Related, as of v37, it appears that salesforce no longer supplies the Bayeux clientId in broadcast messages:
The protocol does not require clientId:
The clientId message field MAY be returned in message responses except for failed handshake requests and for publish message responses that were sent without clientId.
I'm guessing they made this change to reduce the surface area for clientId leakage. In any case, forthcoming PR removes non-null assertions for clientId since it's not there anymore.