[SPARK-3119] Re-implementation of TorrentBroadcast.

This is a re-implementation of TorrentBroadcast, with the following changes:

1. Removes most of the mutable, transient state from TorrentBroadcast (e.g. totalBytes, num of blocks fetched).
2. Removes TorrentInfo and TorrentBlock
3. Replaces the BlockManager.getSingle call in readObject with a getLocal, resuling in one less RPC call to the BlockManagerMasterActor to find the location of the block.
4. Removes the metadata block, resulting in one less block to fetch.
5. Removes an extra memory copy for deserialization (by using Java's SequenceInputStream).

Basically for a regular broadcasted object with only one block, the number of RPC calls goes from 5+1 to 1+1).

Old TorrentBroadcast for object of a single block:
1 RPC to ask for location of the broadcast variable
1 RPC to ask for location of the metadata block
1 RPC to fetch the metadata block
1 RPC to ask for location of the first data block
1 RPC to fetch the first data block
1 RPC to tell the driver we put the first data block in
i.e. 5 + 1

New TorrentBroadcast for object of a single block:
1 RPC to ask for location of the first data block
1 RPC to tell the driver we put the first data block in
i.e. 1 + 1
block size is limited to 4mb iirc - while deserializing two 100mb broadcasts (as mentioned in usecase) in parallel will mean first has to complete before second (or any other) can even start : so 50 requests have to finish (half of which are pulling 4 mb each).
Even assuming both cores are pulling same broadcast, assuming reasonable shuffle and large enough sizes, they could complement each other (best case, reduce time taken by half, worst case, double IO assuming horrible shuffle or single block).
From latency point of view, current option is not very good when waves of tasks are getting scheduled and we have multiple cores per executors : from network IO incurred point of view, maybe it is better.
Tradeoff question is, which is dominating.