MIRTH-3166: Improved how channels are enabled/disabled from the Channels view. Instead of doing a separate request for each channel (and retrieving the channels again after each request), it now only sends a single request via a new Client operation, setChannelEnabled. A set of channel IDs are passed in along with a boolean that determines whether to enable/disable. 

On the server side in the channel controller, setChannelEnabled is synchronized with update/remove so that it can guarantee the state of the cache. Then it iterates through each channel ID and updates the associated channel (if it exists and is valid). If one channel fails to be updated for any reason, the rest are still attempted.

On the client side, only a single SwingWorker is now used. It still checks beforehand whether some of the selected channels are invalid, but it no longer prevents the worker from executing in that case. Instead, after executing the worker it will alert the user at the very end if one or more channels could not be enabled. For disabling this isn't necessary since validation doesn't matter in that case.
MIRTH-3163: Improved how channel statuses are pulled from the server and updated in the dashboard table. Instead of doing a single request and updating the table all at once, it's now pulling down partial lists of statuses (100 at a time) and updating the table incrementally. Some optimization is baked into this; the first call it does is to getDashboardChannelInfo, which returns the initial list of dashboard statuses, along with a set of remaining channel IDs. Then the worker publishes the initial list and iterates through that set, making additional calls to getChannelStatusList to retrieve subsequent blocks of dashboard statuses.

The dashboard panel and associated tree table model have also been updated with methods to update parts of the table incrementally, as well as "finishing" methods to make updates based on the finalized list of statuses.
MIRTH-3187, MIRTH-3188: Fixed issues that occurred when sending/receiving TCP messages without any end of message bytes set on the transmission mode. After the stream handler is finished iterating through the stream (and bytes were not returned by the batch reader or in the loop because end of message bytes were detected), the bytes captured thus far are sent back to the caller. However if end of message bytes were expected, it should have already returned from the normal loop iteration, so an exception should be thrown. Also if the same thing happens when end of message bytes are not expected, then we need to reset the flag that determines whether or not to look for the start of message bytes. If the message was intermediate as part of a batch, it would have been returned in normal loop iteration when checking against the batch reader.