first steps to background git-status update process
webui.gitstatus lock,unlock,kill methods
webui.tasks.gitstatus_update minimally working

- Doesn't yet do the caching the way it's supposed to.
- No way to kill/revoke task if heavier task needs the disk.

NOTE: This doesn't work with celerybeat yet - import is wrong.
supervisord config for celerybeat
updated celery conf and got celerybeat to run webui.tasks.gitstatus_update

So it turns out there are some new things you have to do to have Celery
work with Django.
- Add proj/proj/celery.py
- Point to celery.py in proj/proj/__init__.py
- Celery docs now say django-celery is no longer necessary but they still
  refer to it and the examples still have in settings.py

- Changed @task(name) to an import path ('webui.tasks.gitstatus_update').
  This may be what was causing celerybeat to not import the gitstatus task.
  I thought the name was just a unique string by which celery referred to
  tasks, I didn't know it actually *used* it for imports...

http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
comment out logging in storage.base_path

This function gets run constantly and it clutters up the logs.
funcs for reading/writing gitstatus file; reworked sync_status

- Added functions to webui.models for reading/writing/parsing
  cachefiles for git status, git annex status, and sync status.
- Reworked _sync_status to avoid circularities.
gitstatus log in /var/log/ddr where logrotate can get it
CR at end of each line in gitstatus queue
mod gitstatus_parse so it can deal with not having sync_status
functions for reading/writing/parsing gitstatus files
More complex behavior for gitstatus_next_repo

Simplify by separating steps that were mushed together
- Changed format of queue file: Now consists of collection paths and
  timestamp of last gitstatus update.
- Is there a gitstatus queue file?  If not, loop through collection
  repos on store and make a new one..
- Any collections ready to have gitstatus updated? (e.g. is delta since
  last update greater than interval?)
- If any collections ready, return the first one and update queue.
- If no collections ready, then update queue and return message
  ('backoff' or 'notready') and time til next collection ready to
  update.
record elapsed time when writing gitstatus

Again, the gitstatus update includes
- git status
- git annex status
- sync status in relation to mits
Sometimes it takes awhile to perform.
if repo has no gitstatus file, set for immediate update
refactored gitstatus_update task function

- Works with gitstatus commands that include elapsed time.
- Moved the if/then blocks around for clarity
- log messages hopefully clearer
- return useful info at conclusion: collection path if updated
  or notread message and delta
better gitstatus-update commenting and function documentation
gitstatus_next_repo now gets all the repos/orgs on the store

Instead of just ddr-densho being hard-coded
don't log all the returned statuses in gitstatus_update

- This fills up the logs
- The annex_status[:72] part caused errors if the line sometimes
  wasnt' long enough
only refresh repo/.gitstatus if you really want to. seriously

If there's no .gitstatus and no force is requested, it should
just return nothing rather than loading all the statuses
override Collection.repo_conflicted to use gitstatus if present

I think this may have been the cause of our performance problems
on the collection-detail view.  Underlying code for
alert_if_conflicted() would call git-status which sometimes takes
awhile.  Should now be cached.