Changes to support Bitbucket OAuth2

[agjohnson]

Changes most API calls to use APIv2 and relies on OAuth2 for sessions. Bitbucket's OAuth2
implementation expires tokens after 2 hours, so this also implements token refreshing on
the general session creation.

This updates the UI around connecting accounts, namely:

• Use our common list styling for list of connected services
• Add a basic warning element for guiding users to reconnect accounts
• Make connect services buttons themed buttons instead of basic links
• Updated some of the text from "Social Accounts" to "Connected Services".

The project import page will now warn when deprecated accounts are connected, the new API sync code for Bitbucket uses version 2 of the API for almost all requests. Our API will filter out repos/orgs from these deprecated services, but the services themselves are kept around to allow for user administration on the connected services page.

Refs pennersr/django-allauth#1215
Refs pennersr/django-allauth#1212
Fixes #1675
I believe this fixes #1864
Fixes #1696
Refs #1893 - repin django-allauth next release
Fixes #1684 - "social accounts" rename
Fixes #1668 - social account page 500 error
Fixes #1446 - add bitbucket tests

Outstanding:

• Test handling of existing Bitbucket social accounts
• How to handle migration fo existing Bitbucket social accounts
• UI and styling bits to point users to reconnect
• Some more test cases around bitbucket
• Import form uses HTTP, but complains about "this is a private repo"

[saily]

@agjohnson good job, i was thinking about same kind of implementation using an abstract base class, which you implemented using a non-abstract Service base class.

from abc import ABCMeta
from abc import abstractmethod


class Service:
    __metaclass__ = ABCMeta

    @abstractmethod
    def sync(self, sync):
        pass

    @abstractmethod
    def create_repository(self, fields, privacy=DEFAULT_PRIVACY_LEVEL, organization=None):
        pass

    @abstractmethod
    def create_organization(self, fields):
        pass

    @abstractmethod
    def setup_webhook(self, project):
        pass

Making it abstract would make more sense to me, what do you think?
After this was merged into master i'll rebase #1870.

[ericholscher]

.sync(sync=True) feels like a weird API. Are there times we'll call sync without syncing?

[agjohnson]

I didn't see any, this is brought over from before the refactor. Not sure what sync=false would ever be used for.

[agjohnson]

@saily interesting, I almost settled on a similar pattern. In the end, I kept the pattern here simple, as we have some complications with inheritance for readthedocs.com. There's a good deal of common functionality implemented in the base class, so I think it's fair to consider services as subclasses of this class anyways.

[ericholscher]

Do these SocialAccount's get removed when they set up their new account? Or are we expecting them to "unlink" them?

[agjohnson]

Yeah, it requires manually unlinking them in the connections page. Or, rather, both can exist, we just need the Bitbucket OAuth2 provider. So as long as the user sets that up, everything will work -- albeit there will be a warning still. I considered making a view that unlinks the account and redirects to django-allauth, but felt that was over-complicating the issue.

[ericholscher]

LGTM 👍 -- definitely happy to have this stuff sanely refactored.