Switch to django.contrib.staticfiles

[singingwolfboy]

This allows us to pull in new features and bugfixes from the mainline of development for both django.contrib.staticfiles and django-pipeline, rather than using our forks of these projects.

This PR was inspired by #1889 -- which would not have broken the build if we were using django.contrib.staticfiles. The bug that bit us was caught and fixed by the Django development team a year ago.

[cpennington]

We had a handful of changes in each of our forks. Have you verified that they are no longer needed (either because we no longer use whatever they added, or because they've been addressed upstream?)

[cpennington]

Also, please make sure you test this on a sandbox (or some other environment that actually has pipelining turned on), just to be sure that it actually works. Perhaps you could use @wedaly's end-to-end tests?

[singingwolfboy]

@cpennington Those changes appear to be solely focused on logging. How important is that? I haven't yet checked to see if the relevant lines have been added upstream.

[singingwolfboy]

I deployed this branch to a sandbox server, and it seems to work fine -- all static assets are built and packaged up properly, as far as I can tell.

[singingwolfboy]

@jtauber You should be aware that this PR removes our forked version of django-staticfiles from the codebase entirely (using Django's built-in django.contrib.staticfiles package instead), and replaces our forked version of django-pipeline with version 1.3.19 of the mainline project.

[cpennington]

edx/django-pipeline@cyberdelia:master...88ec8a0 seems to indicate a number of changes, including stuff about unicode, in-place compilation of files, forced recompiles, and possibly others.

[cpennington]

We're only on django 1.4, which means that django/django@1aa0d8a isn't live in our version of django.

[singingwolfboy]

@cpennington I hadn't realized that, but I still think we should make this change. When we upgrade our version of Django, we'll be able to take advantage of all of Django's improvements, including improvements to django.contrib.staticfiles -- and it will reduce the risk of the upgrade, since we would be closer to a default configuration, rather than using an old version of staticfiles with a new version of Django.

[cpennington]

I believe that the staticfiles that we forked from is newer than 1.4's included version of static files (although I'm not 100% sure of that). If that's the case, then the question of "what's the diff" comes up again.

[singingwolfboy]

Unicode fixes have been merged into the latest version of django-pipeline. In-place compilation and forced complication can easily be reimplemented by creating our own Compiler subclasses. It looks like the only place we use in-place compilation is in lms/envs/common.py, and it appears to be only an optimization for development. It doesn't appear that we use forced compilation anywhere.

[singingwolfboy]

@cpennington You're right -- our version of the staticfiles library is newer than the bundled django.contrib.staticfiles for Django 1.4. As a result, I'm closing this pull request in favor of #1966. This branch will be very useful after we update our version of Django, so I'm not deleting it; but since it's not being actively worked on, I'm closing the PR.