Now that the Jabber settings functionality is refactored into its
own Django app, we don't need this test in the Courseware Django
app.

Rename get_password_for_user to get_or_create_...

The new name describes more accurately what the function does: it
creates a new password for the user if it can't find one in the
database.

Move DEFAULT_PASSWORD_LENGTH to JabberUser model

This seems more appropriate as a property of the model as opposed
to a loose constant in the utils module.

Random string generation returns proper length

Before, the length was only accurate if it was a multiple of four.
Now, we calculate the number of bytes needed from /dev/urandom
properly and we truncate the string to just the right length.
(Base64 returns strings that are a multiple of four in length, but
we truncate since we won't ever care to decode the string.)

Adding working utility tests for Jabber app

The majority of the functionality of the Jabber app is in the utils
module, so we test those functions thoroughly.

The test settings don't currently have settings to connect to a
Jabber database (need @jrbl's help to get the migration files to set
it up properly), so we temporarily skip tests that hit the Jabber
users table.

Add migration for Jabber users table for testing

In testing environments, we want to be able to interact with the
database as we create JabberUser instances. This commit adds a
migration for the purposes of testing; the migration should *not*
be used for anything else though. The actual Jabber users table
should be created by ejabberd during provisioning.

Unskip Jabber tests that interact with database

Now that we have a migration for the Jabber users table in the test
environment, we can hook it up in test and "unskip" the tests that
hit that table.

If no default is provided, sass falls back to the system
default. This fails when the system default is not unicode because
various sass files have unicode characters in them.

As stipulated by Stanford's office of general counsel

By linking the users

modification of @jrbl's version to handle a dict with value None

(cherry picked from commit 14100ba1)

(cherry picked from commit 832da3ad)

(cherry picked from commit 050846af)

(cherry picked from commit 664efb98)

(cherry picked from commit a17bf5e2)

(cherry picked from commit 273df4e1)

(cherry picked from commit c96511a2)

(cherry picked from commit 1511ec84)

(cherry picked from commit d2554909)

This was 7b7a3427, which became an empty commit after we rewrote history to
remove 42650ab3c.

* In addition to the JABBER settings, now we want to be sure to get
  DATABASE_ROUTERS, too.

Conflicts:
	lms/envs/common.py

Merge remote-tracking branch 'origin/feature/nate/simple-chat' into edx-west/release-candidate-20130613

Conflicts:
	lms/templates/courseware/accordion.html
	lms/templates/courseware/course_navigation.html
	lms/templates/courseware/progress.html
	lms/templates/navigation.html

/dev/random blocks if there is not enough entropy to return the
requested number of bytes, and this turns out to hang our AWS
servers. When generating random bytes for Jabber passwords, use
/dev/urandom instead. We figure that this will be "secure enough,"
since we'll have bigger problems if someone manages to get ahold
of our /dev/urandom's seed value.

Add utilities to the Jabber app to parse the Jabber settings and
build the URLs, chat room names, and user passwords for connecting
to ejabberd. This is a WIP commit since it still needs tests (in
progress...stubbed out with comments).

In the initial theming pass, we missed two error pages. This commit
replaces edX values with PLATFORM_NAME and TECH_SUPPORT_EMAIL
settings.

When chat is enabled, sync user accounts with the ejabberd server
by directly writing into its MySQL database. This is ugly in the
sense that ejabberd just does a simple string comparison when
authenticating a password against a username, so we have to send
passwords in the clear in the templates. In a future commit, I'll
implement a password rotation mechanism to make this slightly more
robust: currently, everyone's password is just a dummy string.

To enable this, you'll have to add a 'jabber' key into your
DATABASES dict in the settings, and point at an actual ejabberd's
MySQL instance. The current plan is to just point at one that we've
got set up, since running ejabberd locally (not to mention on
MySQL instead of Mnesia) is non-trivial.

Rather than checking to see if the JABBER_DOMAIN is not set and
continuing on, bail with an ImproperlyConfigured exception as soon
as we notice its absence.

Per
https://edx-wiki.atlassian.net/wiki/pages/viewpage.action?spaceKey=ENG&title=I18n+coding+guidelines
ensure that chat messages are properly internationalized.

Only render the chat widget if both the site has enabled it in the
`MITX_FEATURES` and if the course has enabled it. In addition, fail
gracefully with a log warning if the `JABBER_DOMAIN` is not set, and
do not try to render the widget. However, do go ahead and render the
rest of the courseware.

To protect against chat blowing things up, we include a way to
enable and disable it on an entire site-wide basis.

Ensure that the chat connection settings are generated properly for
the template context.

jQuery already available across the whole site at the top level, so
no need to include it again specifically for the chat widget.

Embed a chat widget (much like the calculator widget) into the
courseware. To use, you must point it at an ejabberd box,
configured as `JABBER_DOMAIN` in the settings.

Fix typo and an unclear description.

[STUD-256] Seems like on chrome when cancel is hit in the file chooser, the 'change...

Fix broken lettuce tests