We are going to enable this for all the projects with the FF by default
now, which means that there isn't going to be a relationship between
`Project` and `Feature` once it's deployed.

This formula considers builds that are retried multiple times.

We want to skip the default permsissions check here (done at
`get_queryset()` method) because it filters the object by build API key
and/or user access.

Since we are making an anonymous request without a build API key, we
need to skip this check and base it only on the `?builder=` GET
attribute.

Common changes across providers:

- A new method to just update a remote repository from the data returned
by the API was added, this is in order to make it easy to re-use this
method when support for updating a single repo is added (will do this in
another PR on top of this one).
- We were iterating over repositories twice for GitHub and BB, once by
listing all the repositories the user has access to, and then again by
iterating over all the repositories from the organizations the user has
access to, this was also incorrectly adding a relationship between the
user and repositories the use didn't actually have access, as that
endpoint will return all public repositories, even if the user doesn't
belong to it.
- sync_organizations now basically just creates the user-organization
relation only.
- Since several repositories can belong to the same organization, we
don't really need to update the same organization over and over again,
just once, so a cache was introduced for it. This is also a reason why
the creation of the user-organization relationship was moved outside
`create_organization`.

Specific changes:

- For Bitbucket, we weren't updating a repository if the workspace it
belongs was changed, we now update those. This is the same problem we
had with Gitlab
#12233.
- For Bitbucket, we were creating the repo-user relationship and then
updating that relationship for the repositories where the user is an
admin. This wasn't resetting the admin status to false for repos the
user no longer had that permission, we now always default to
admin=False, and then we update the repositories where the user is admin
in the other call.
- In Bitbucket, we don't have organizations, we have projects and
workspaces, we are using workspaces as our organizations. But in BB,
every repository is linked to a workspace (a user can be a workspace),
so we always create an organization for each repository.
- Since all other providers are fetching all repositories in the
`sync_repositories` method, I changed Gitlab do also do that. In order
to do that I reverted to use the previous /projects endpoint
(#12233).
- GitLab sometimes returns avatars with a relative URL `/~/uploads...`
instead of including the domain as well, so we are normalizing all URLs
from Gitlab now.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Filter by `date` to use one of the fast DB indexes we have in the
`Build` model.

Solves https://read-the-docs.sentry.io/issues/6806637157/

Fixes https://read-the-docs.sentry.io/issues/5537486737/

Attempt to fix the auto-upgrade from
#12434

This setting is overridden in .com, so this tests fails

…12438)

See #12433

`clean_build` is not called when the task is terminated and there could
be some lingering files around. Instead of only deleting the files for
the current build, we delete the whole `settings.DOCROOT` path when the
build starts.