I think it's probably time to bite the bullet and make modifyAccount take and call a callback.  I put the comment there originally because we didn't do anything complex so modifyAccount was largely synchronous but I felt guilty about what I was doing.  Also, we had very strong ordering guarantees so ping() was a reasonable hack.

We've since modified MailUniverse.saveAccountDef to do more stuff (_cronSync.ensureSync() gets called) and I think it's arguable that our high level "change our password" flow should just be "modifyAccount()", not "modifyAccount(); clearAccountProblems()", which would want a proper callback.  Having said that, I don't think we want to undertake that flow change right now (or maybe ever) for passwords.  Password changing is the type of thing where it does seem reasonable to assume the password is being changed for a reason and that the user didn't make a typo.

(I think the ideal for-engineers UX flow might actually be for us to associate some kind of mini-toaster spinner that says "we're verifying your account right now" while we're doing the check.  When the check completes successfully we say "yeah! it worked", if we experience a connectivity issue we say "can't tell if it worked; we'll assume the best", and if we experience an auth failure we go back to full screen and say "oh no, you made a typo or the server is just broken. crap!")

I think it might be best to even put a do_modifyAccount() helper on the testAccount so it can wrap all of this and set appropriate expectations in the future based on what we're passing.  This will help us make sure that the asynchronous processes we trigger all run within this test step.  Otherwise modifyAccount is going to end up as a source of intermittent test failures.

I'm definitely open to feedback on this/general long-term gameplan for modifyAccount.