Awesome deploy

This commit introduces a new fab command, `awesome_deploy`, that preindexes and, provided preindex completes quickly, deploys. For 90% of deploys, this reduces deploy to a single step.

This PR touches functions used in current normal deploy only minimally: makes preindex log its completion to redis and adds a way to check for completion; splits deploy function up. Neither of these should affect normal deploy. I propose we keep using normal deploy for another few days, but use `awesome_deploy` on staging. To that affect, I've also changed the rebuildstaging `--deploy` option to use `awesome_deploy`.
The key includes the commit id, and the check is always run after
update_code, so the question it asks is "has preindex been run for *this
code* in the last 24 hours?"
On Jun 22, 2014 2:59 AM, "Cory Zue" <notifications@github.com> wrote:

> In corehq/apps/hqadmin/management/commands/preindex_everything.py:
>
> >          if email:
> >              mail_admins(subject, message)
> >          else:
> >              print '{}\n\n{}'.format(subject, message)
> > +
> > +rcache = cache.get_cache('redis')
> > +PREINDEX_COMPLETE_PREFIX = '#preindex_complete_%s'
> > +HELL_YEAH_IT_IS = 'hell yeah it is'
> > +
> > +
> > +def set_preindex_complete(head):
> > +    key = PREINDEX_COMPLETE_PREFIX % head
> > +    rcache.set(key, HELL_YEAH_IT_IS, 86400)
>
> might not be reading this closely enough, just wondering how this gets
> invalidated. like if we deploy view changes in the same day a preindex
> happened where is the protection for that?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/dimagi/commcare-hq/pull/3678/files#r14053274>.
>