Base branch for deleting not guaranteed to exist

[joshtemple]

In the branch manager, when creating a temporary branch, we save the name of whatever branch the user is on in dev mode (let's call it the Initial Dev Branch). This is because we will eventually need to delete the temporary branch and we a) can't delete a branch we've currently checked out, and b) can't delete from production workspace. We save that Initial Dev Branch to checkout again later so we can delete the temp branch and restore Git state nicely as we found it for the user.

Problem: Sometimes, the Initial Dev Branch is deleted by a different run, which means we get an error when we try to check it out again in the first run.

I've seen this occur when two runs are running concurrently. Run A creates a temporary branch (Temp Branch A) and begins testing. Meanwhile, Run B starts and saves its Initial Dev Branch (which, for reasons I can't quite explain, can be Temp Branch A, even when Run B is started by a different user. Or at least, I think it's a different user. It's hard to verify which user is running Run B because we don't log the user's client ID. We should fix this.). Run A finishes and deletes Temp Branch A during cleanup. Run B finishes and tries to restore to its Initial Dev Branch, which is Temp Branch A. That branch no longer exists so we get an error.

Proposed solution

Instead, we could use a personal/dev branch as this home base, which can't be deleted. This guarantees we always have somewhere we can delete the temp branch from.

From the Looker docs:

Your personal branch is specific to you, and it cannot be deleted. Your personal branch is read-only to all other developers. If you are collaborating with other developers on a project, you may want to create a new branch so that others can switch to that branch and contribute changes as well.

I don't see a way, using the Looker API, to get the personal branch of the current user. But it doesn't matter which personal branch we go to, as long as we go to something that's guaranteed to exist.

[joshtemple]

After a bit more debugging, it seems this issue happened because a customer had set up multiple API keys for a single Looker user instead of using multiple Looker users for concurrency. That's going to cause this issue regardless of the proposed fix in #563, so I'm open to closing this since it's unlikely that this would occur otherwise.