TNL-1244

re-shard cms lettuce tests back to 1 shards

Revert "Add pylint plugin to check whether setUp is called in ...

This reverts commit a92ca9d7.

Upgrade: Font Awesome 4.3.0

Fix pep8 violation

Use new modulestore override paradigm in the new testcase

Update default video that appears when adding a new Video component

Info-level logging for certificate management commands

Clean up ModuleStoreTestCase

Update privacy policy date to the most recent

Internationalize aria-label attributes

Change name and email modal couple of accessibilty issues

(WIP) Unicode fixes for log messages with username and other unicode input

Delete unused student_profile API.

Add dcikatic, dsego and mjevtic to the AUTHORS file

Search form accessibility

The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.

In a structure like:

    @override_settings(MODULESTORE=store_a)
    class BaseTestCase(ModuleStoreTestCase):
        def setUp(self):
            # use store

    @override_settings(MODULESTORE=store_b)
    class ChildTestCase(BaseTestCase):
        def setUp(self):
            # use store

In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.

To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.

[PLAT-419]

Refactoring the mocked user service object to return xblock user.

Invoice data model refactor

Conflicts:
	lms/djangoapps/shoppingcart/views.py