Add atomic transaction around social_auth creation.

[doctoryes]

Since Django 1.6, a transaction.atomic decorator has been available. There's a pattern that's supported in python_social_auth that performs a Django ORM operation and then handles a possible IntegrityError raised by the operation - see here:

https://github.com/omab/python-social-auth/blob/master/social/pipeline/social_auth.py#L40

This pattern is even documented in the Django docs:

https://docs.djangoproject.com/en/1.6/topics/db/transactions/#django.db.transaction.atomic

However, if an IntegrityError is raised without being in a transaction.atomic block (via decorator or context manager), the transaction itself is left in a "broken" state - and any subsequent transaction operations will fail with the following exception:

An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

This condition is not detected in the current unittest suite because the IntegrityError scenario is tested by using a simple raise with no actual DB transaction:

python-social-auth/social/tests/test_pipeline.py

Line 21 in aa66b83

raise IntegrityError()

This PR attempts to fix the broken transaction scenario. I've tested it with our https://github.com/edx/edx-platform test suite and it fixes the broken transaction. As a workaround for our Django 1.8 upgrade, I've monkey-patched edx-platform to fix the issue - that commit can be seen here:

edx/edx-platform@699ae37

The fix in this PR may not be the preferred one - but it does at least fix the issue. I'm happy to provide more information if needed.

[doctoryes]

@omab FYI - for your review - thanks.

[carsongee]

This is just what I needed, thanks @doctoryes

[doctoryes]

@carsongee Pleased that it helped you!

[omab]

Closing since this is already in the codebase https://github.com/python-social-auth/social-app-django/blob/master/social_django/storage.py#L112.

Thanks!