Add _get_next_allocation method; remove duplicated logic from _loop

Implements Kevan's refactoring of _loop:

"This is essentially a copy-and-paste of tracker and share selection
logic from within _loop to _get_next_allocation. Now,
_get_next_allocation is responsible for telling _loop what to do (i.e.,
which server to use, and which shares to store on that server), and
_loop is responsible for doing what _get_next_allocation says to do.
This isn't a big change right now, but allows us to move to an external
peer selector object more easily (and obviously) in the future.

This also unifies the log messages for success and failure, and the
exception messages printed on a failure. Before, users would see two
slightly different messages depending on where in _loop the allocation
was noted as successful (or unsuccessful). This commit chooses the more
verbose form of these messages to be used on all successes and failures."
Add IPeerSelector interface from #1382

Adds the IPeerSelector interface established by kevan in ticket #1382
Implements PeerSelector class to track peerids

Implements the IPeerSelector class as PeerSelector and integrates the
class into Tahoe2ServerSelector in order to track peerids and existing
share allocations among the peers
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 sets for existing_shares instead of lists
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
Happiness_Upload now takes in full_peers

The PeerSelector now passes the set of full peers to Happiness_Upload.
Also removes the case in which no servermap is supplied from
generate_mappings because the case is redundant.
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
Removes 'todo' from unit tests that are fixed by the new uploader and removes
tests that were specific to the old algorithm.

test_second_error: There is no concept of a third pass for the new algorithm.

test_problem_layout_ticket_1118: As noted in the comments this should pass.
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.
Fixes issue in test_problem_layout_ticket_1128

Deleting the storedir breaks the test server by setting the remaining
free space to 0, and therefore the server will refuse any shares even
if the placement algorithm is correct. This removes the shares from
server 0 without corrupting its other properties.
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
Queries for Upload of Happiness should be 2 not 1

Unlike the previous algorithm, Upload of Happiness should make
two queries to the servers instead of one. The first query is to
ask about existing shares and the second query to ask the server
to store some shares for us.
Happiness Upload will not place shares in these cases

Happiness Upload will not place shares unless it knows it can
be succesful. Therefore for these tests, a partial placement
of shares will not occur.
Improves logging for error messages in new uploader