Improve instance polling behavior

[bodom0015]

Problem

When a user launches a Tale instance, the UI will poll for its status until it finishes. If the user refreshes their view, the poller does not reactivate. Similarly if the user logs out, the poller continues to run and spit out many errors.

Fixes #488

Approach

I have rewritten the current looping logic into generic waitFor functions in the api-call service - these helper methods were to be introduced in the refactored run/browse view PRs, but I have fast-tracked them here instead since they seem pertinent to the issue at hand. Note that I have not replaced all existing loops/polls with this helper as of yet, as this will likely cause merge conflicts within the other refactoring branches (where this has already been done).

• On init, check if any instance in launching (if true, poll until it finishes)
• Stop polling if an error is hit

NOTE: We are still working on building out the notification-stream patterns, so maybe it would be best to use that to receive async updates from Girder, rather than polling at all.

How to Test

Prerequisites: no Tales currently running or launching

1. From deploy-dev, run ./destroy_instances.py to ensure no running/launching instances exist
2. Checkout and run this branch locally, rebuild the dashboard
3. Open an incognito window and log into the WholeTale Platform
4. Open your developer console to the Networks tab
5. Launch a Tale from the Browse view
   • You should see the Networks tab receives a GET /api/instance/:id response every ~1 second
6. While the Tale is still launching, refresh the view
   • You should still see that the Networks tab receives a GET /api/instance/:id response every ~1 second
7. While the Tale is still launching, log out of the WholeTale Platform
   • You should see a single 401 error come through
   • The polling should stop - you should only see one error per poll that was running

[Xarthisius]

@bodom0015 could you please rebase?