Implements Happiness_Upload class

Implements the Happiness_Upload class to generate a maximum
matching of peerids to shareids based on Kevan Carstensen's
master thesis. Existing share allocations are reused if possible
and their leases should be renewed by the uploader. If a shareid
does not have a match in the maximum matching graph, its
respective peerid is set to 'None'.
PeerSelector uses Happiness_Upload

PeerSelector uses Happiness_Upload to implement get_tasks
and is_healthy. In order to do this PeerSelector now requires
the parameters num_segments, total_shares, needed_shares, and
servers_of_happiness from Tahoe2ServerSelector when initialized.
Implements PeerSelector into Tahoe2ServerSelector

Initial attempt to refactor Tahoe2ServerSelector in terms of
the PeerSelector. This does not pass all of the existing
tests in test_upload.py
PeerSelector passes in full_peers
Fixes construction of peer priorities

Fixes an error in _distribute_homeless_shares where the loop
was trying to assign a priority to full_peers when full_peers
are not present in the priority dictionary. If the loop encounters
a peer that is full, it just skips over that peer.
Adds edge situation where servermap is empty
Adds edge case to _distribute_homeless_shares

Adds exception to _distribute_homeless_shares that caused
tests to hang indefinitely.
Refactors _get_next_allocation

Refactors _get_next_allocation so that peer_selector.get_tasks()
is only called once instead of during every allocation since
the operation is relatively expensive. Write servers are queried
for existing shares after the readonly servers, and then tasks
are calculated.
Adds edge case when happiness can't be met
Calculates maximum matching from readonly servers first

In order for happiness_upload to return a happiness of 3 on
test_problem_layout_ticket_1128 in test_upload.py, the readonly
servers must have a higher priority than other existing shares.
Removes some unnecessary parts from old uploader
Improves logging for error messages in new uploader
Adds failure message to _got_response_2
Removes extra +1 to number of servers contacted
Makes download finder deterministic

While the previous algorithm would reliably distribute shares
in increasing order to the trackers, Upload of Happiness doesn't do
this. This causes the finder to query for a random set of shares based
on the order shares are allocated by the uploader. In order for the
finder to have a reproducible behavior, the finder must sort servers
by their server id because Upload of Happiness tracks servers by server
id in a set.
Peer Selector tracks allocations accepted by the server
Cleans up happiness_upload.py
Reframes test_each_byte in terms of share 2
Removes error in establishing servermap_peers
Cleans up upload.py