Improve a race condition in session establishment code

Summary:
If you try to establish several sessions quickly (e.g., by running several
copies of "arc" at once, as in "arc x | arc y"), the current logic has a high
chance of making them all pick the same conduit session to refresh (since it's
the oldest one when each process selects the current sessions). This means they
all issue updates against "conduit-3" (or whatever) and one ends up with a bogus
session.

Instead, do an update against the table with the session key we read, so only
one process wins the race. If we don't win the race, try again until we do or
have tried every session slot.

Test Plan:

• Wiped conduit sessions, ran arc commands to verify the fresh session case.
• Ran a bunch of arc piped to itself, e.g. "arc list | arc list | arc list |

...". It succeeds up to the session limit, and above that gets failures as
expected.

• Manually checked the session table to make sure things seemed reasonable

there.

• Generally ran a bunch of arc commands.
• Logged out and logged in on the web interface.

Reviewers: btrahan, jungejason

Reviewed By: btrahan

CC: aran, btrahan

Maniphest Tasks: T687

Differential Revision: https://secure.phabricator.com/D1329