Hide unnecessary debugging information

There were previously a number of places in our code where debugging
information was always being output.  This was cluttering the output
during test runs, without adding any utility.

This commit makes debugging information get suppressed by default, but
allows debugging to be turned on with optional boolean function
arguments.
Removes SR4 expire_unsent_emails migration check
Fixes bugs in LSRAssignmentTest
Adds customforms classes to shell_utils

Auto-import customforms classes in shell_plus.
Code cleanup
Fix how JSONDataModule is added to created program

Refactor how the JSONDataModule is added to the program_modules field of
the ProgramCreationForm.  Perform the addition in a clean_FIELD()
method, rather than directly in setup.py.

By default, a Django ModelForm will take the raw input for a
MultipleChoiceField and coerce it into a list of strings, even if the
real data should be something else (in this case, a list of integers).
The original code checked this list for the id (an integer) of the
JSONDataModule, and added the module if it was missing from the list.

In theory, this should lead to an error.  The integer would always be
missing from the list of strings, so if the JSONDataModule was already
in the list (which is always the case during testing, or when the admin
creating the program correctly selects it), it would get added a second
time.  Then, when the program_modules field gets saved into the new
Program object, an error would be generated for having a duplicate entry
in the many-to-many relation.

For some reason that I don't know, this error never actually manifested
itself previously.  However, I ran into it when making changes to how
testing runs.

This refactoring fixes the problem I ran into.  During value coercion,
we map the string ids into integer ids, and then add the integer id for
the JSONDataModule if it is missing.
Revert "Add trivial test of repeat syncdb and migrate commands"

This reverts commit d387d646a21f15564f25b3d6802f103663f2f8b2.

Removes DBOpsTestCase.  There is no reason to test ./manage.py syncdb
and ./manage.py migrate from inside ./manage.py test.  By the time this
test case runs, one or both of those commands would have already run
successfully anyway.  And if migrate hasn't already been run, then it
shouldn't be run in the middle of testing.  Also, the tests weren't even
running as intended (as described in the original commit message); the
test runner executes test methods in alphabetical order, so the test was
really executing migrate followed by syncdb.

Conflicts:
	esp/esp/utils/tests.py
Corrects typo in program post_syncdb()

program_program_class_categories is the table for the many-to-many
relationship between Program and ClassCategories, via the
Program.class_categories field.  It is not, as intended, the table for
the ClassCategories model, and it does not have a seq column.

Fixes this by using ClassCategories._meta.db_table instead.
Prevents IndexError by ensuring web.install() runs
Makes the post_syncdb() functions idempotent

Previously, they were run-once functions.  This works fine when starting
a site or when running ./manage.py test with south migrations enabled;
in the latter case, ./manage.py test is overridden from the original
Django implementation, and runs ./manage.py syncdb, followed by an
overridden no-op ./manage.py flush, followed by ./manage.py migrate.

However, when south is not enabled during tests, the Django
implementation runs ./manage.py syncdb, followed by ./manage.py flush.
The ./manage.py flush command is also executed before execution of every
test method of a TransactionTestCase subclass.  The post_syncdb signal
is sent after successful completion of both commands, but under the
previous code, the post_syncdb() functions are not run after the
starting ./manage.py syncdb.  This means that at the start of testing,
and at the start of TransactionTestCase test methods, the database is
empty and missing its required data, which was supposed to be installed
by the post_syncdb() functions.

This commit makes the post_syncdb() functions idempotent, so that they
can be run successfully multiple times.  After a post_syncdb() function
is called (with the correct app as an argument), it is now guaranteed
that the initial data will be correctly installed in the database.

In the instances where this wasn't already the case, the install()
functions were also changed to be idempotent, in order to guarantee the
idempotence of the post_syncdb() functions.
Ensures default accounts are installed

Calls GlobalAccountingController().setup_accounts() on post_syncdb.

This was previously only done in the accounting migration
0002_accounting_data.  If migrations were not enabled, the required
accounts would not be installed.

This allows tests that require accounts to run successfully even if
south migrations are disabled during testing.
Ensures customforms schema is created

This was previously only done in the customforms migration
0008_add_schema_customforms.  If migrations were not enabled, the
required schema would not be created.

This allows customforms tests to run successfully even if south
migrations are disabled during testing.
Disable south migrations during testing

Since testing begins from a fresh database, schema migrations are
unnecessary to run at the beginning of testing.  The Django standard
syncdb should be sufficient.  Our post_syncdb() handlers take care of
installing anything that needs to exist in the database at all times,
data migrations don't need to be performed on empty database tables, and
fixture migrations aren't needed during testing, since tests use their
own fake test data.
Add explicit transaction management for customforms schema creation

For some reason, using Django's transaction.commit_on_success() context
manager was not sufficient to prevent the "current transaction is aborted"
error on future queries.  Looking at SQL logs, it appears that the
database is already in a transaction when the CREATE SCHEMA query is run.
This is no problem by itself.  However, after the query failed (e.g. when
the schema already existed), Django was not rolling back the transaction.
I believe this is because our custom query didn't cause the database
backend to set its _dirty flag, but I'm not sure.

Anyway, this replaces the context manager call with an old-style
try/except with explicit commit and rollback.  An extra commit is run at
the beginning in order to flush any existing transaction.

The database backend is now accepted as an argument to create_schema(),
just to allow code reuse in our migration (see next commit).

We wouldn't have noticed this problem if customforms.install() (and all of
the other install() methods) were called only once, but that is a separate
issue.
Use create_schema() function in migration to avoid duplicate code
Fix indentation on create_schema()
Merge pull request #1300 from learning-unlimited/jmoldow-test

Disable south migrations during testing