Improved the pruner/archiver. The end result is that memory usage has been heavily optimized and performance for both pruning and archiving is on average significantly faster now.

Removed the exclude list, include ranges, and exclude ranges strategies. Now there is only a single strategy that utilizes two different queries. For blocks of message Ids that are contiguous and greater than the block size, a separate query will be used to remove each range. For block of message Ids that are not contiguous and less than the block size, a separate query will be used with a list of message Ids (up to 1000) until the next block. This prevents the out of memory errors that are part of the original issue.

Improved the storage of all message Ids that need to be pruned (previously used for archiving, or for SQL Server and Derby). Instead of storing all the message Ids individually in an array list, message ids that are contiguous will be compressed into a range block. For instance, if messages 1 - 1000000 need to be pruned, it will be stored as two long values, 1 and 1000000, instead of one million separate long values. If only message id 500000 is missing, the message ids will be stored as two ranges. The amount of memory required to store the full list of message ids will never be greater than the old method of storage.

Postgres, MySQL, and Oracle no longer use the pruneChannelByDate methods. This was actually slower to prune and slowed message processing more than the other method, so now all the databases use the same method of pruning by first retrieving all the message Ids first. The list of ids are compressed but the query that retrieves the ids is now split with an internal block size of 100,000. Also we are now only retrieving the message id and received date when archiving is off.

No longer using offset in the query to retrieve messages to prune or archive. Instead we are now using minMessageId. 
Issue: MIRTH-3147