Bad state when deleting then re-registering dataset in succession

[bodom0015]

Steps to Reproduce

From #424 (comment)

1. Refresh the page
2. Register/reassociate a dataset
   • NOTE: can be a new dataset, or one you've already registered before, or even one that is still registered to your user
3. Delete the dataset you just registered
4. Without refreshing, register/reassociate the same dataset that you just removed
   • NOTE: This is the step that puts the user into a problematic state
5. Click the other navs, then click back to Manage > Data

Expected Results

• Deleted dataset should disappear when removed and reappear when re-registered
• User's Registered Datasets should be shown after navigating back to Manage > Data
• No error messages appear in the console

Actual Results

• Deleted dataset disappears when removed in step 3, but never reappears when re-registered in step 4
• When navigating back to Manage > Data, the User's Registered Data list never displays
• No error messages appear in the console
• Only a hard refresh can correct this state - navigating to Run and back or changing navs does not correct the issue

More investigation is needed to figure out exactly what is happening there

[bodom0015]

Still looking into this one, and I think I've tracked it down... when we hit the error state, it seems that we are actually winding up in this error-handler: https://github.com/whole-tale/dashboard/blob/master/app/components/dashboard/manage/left-panel/component.js#L163-L165

It would seem that I forgot to fill out this .catch() handler, which currently prints nothing and then returns. As a result, we never hit the .then() above, and never see the new dataset list added after a delete.

The error stacktrace that was being suppressed is similar to the one reported in #395:

"Error: Attempted to handle event `pushedData` on <dataset:5c5cad3573e02b0001349a06> while in state root.deleted.saved. 
    at new n (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:1867:13)
    at e._unhandledEvent (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:10849:121)
    at e.send (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:10838:19)
    at e.pushedData (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:10835:429)
    at e.setupData (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:10835:86)
    at o._load (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:11047:10)
    at o._pushInternalModel (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:11066:12)
    at https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:11063:24
    at e._run (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:1664:94)
    at e._join (https://dashboard.local.wholetale.org/assets/vendor-3fec92aafa2a46ab1024fb73ecea7c3c.js:1663:327)"

This bug seems to occur when Ember.js attempts to automatically reload a model that has since been deleted from the server (e.g. when reload / backgroundReload set to true). As with the bug's previous occurrences, I do not know of a way to fix this once it occurs without refreshing the view.

[bodom0015]

This will likely need the same type of fix as was used in #610 ...