Restart Bayeux

Fixes glitch causing infinite handshaking after restarting Bayeux in some circumstances.
Fixes glitch that would ignore replay IDs that were given to individual channels rather than overwriting the global client level replay ID.

Restart Bayeux glitch

Fixes a glitch in Bayeux streaming after restarting a connection which could cause clients to issue handshakes forever.

The year 2020

Updates all of the underlying packages to the year 2020. Welcome to the future, Salesforce SDK, you made it.
JMS updates breaks backwards compatibility if your software is using JMS for anything, so be wary of changes from upgrading from v1 to v3 of JMS.

No Recursion Bayeux

The Bayeux client was using recursion to continually call the connect() function, which led to an infinitely growing function call stack and after a few days of that even the most robust server with deepest memory banks will give out.
This changes the bayeux client to a state pattern that allows each state to transition to another state, and the bayeux client, after being started, will just call handle() on its current state in a loop instead of recursively calling connect().

This does change up the order in which some things are occurring, even if all the same channels are called in the same order. Make sure to test your usage of the streaming client channels if you are subscribing|extending to any of the Meta channels.

Don't cross the streams

Removes the save_to header from the result request.

Serialize it!

Fixes issue with the CompositeSObjectHandler where the params key wasn't being set when passing the SObject data down the chain.

Late Summer Housecleaning

• Fixes to CSV getContents using a generator
• Fixes to CSV write allowing an array that writes to the file using fputcsv
• Enhancements to ReplayExtension to allow setting Replay Ids for specific channels.

Fixer Upper

• Inject Rest Client into SObject and Composite Clients and use the Rest Client to send requests, consolidating configuration
• Update and test Apex Rest method

Summer '19 Updates

• Add support for declaring version
• Add support for Sforce-Call-Options header
• Add support for Sforce-Query-Options header

See it, Believe it

CometD Messages from Salesforce don't always have successful set to true. It's implied that if successful is not false, then there is no error, and this is corroborated with a valid message payload and no error message. To prevent false positives when checking for errors, success is defaulted to true.