Fix logging in migration task

[rudigiesler]

Currently, for a few of our logs in the celery task, we're referencing values on the migration object. But when we're updating the object, we're updating it in an atomic way, by doing a select + update. This has the side effect that the local django object doesn't get updated, so we are logging the old value on the migrate object.

This PR fixes this issue.

[dubesoftware]

Just wondering why the MigrateSubscription object is declared and assigned several times and not declared once at the top of the function and then referenced further down. Does model.save() return None in our current Django version?

[rudigiesler]

@dubesoftware The issue here is that it's possible at any time for a user to click the Cancel button while the task is running, so whenever we update the model status, we need to do it in a locking/atomic way.

I've achieved this by doing a .filter(id=model.id, status=status_we_expect).update(status_to_change_to), which doesn't return the updated model, just the number of models updated. So if the number of models updated is 1, then we know that the status was what we expected, and has been updated. But if the number of models is 0, that means that the status of the model has changed, and that we should stop processing.