Remove DEDUPLICATE_BUILDS feature flag

[humitos]

We have been testing this for some weeks now and we haven't seen any issue with
it. We are ready to remove the feature flag and make this the default behavior.

[stsewd]

You can also do a final test by making the flag Historical default is True

[ericholscher]

Yea, let's set the feature flag for a week before we fully remove it.

[ericholscher]

Waiting on setting the feature flag to historical_deafult_true for a week.

[stsewd]

I have marked this one as default true today.

[humitos]

@stsewd @ericholscher are we ready to merge this PR now?

[stsewd]

There were some problems with one of our repos, not sure if we want so solve that first.

[ericholscher]

Yea, I feel like without being able to cancel a build, you can get stuck in a state where it's getting deduped but the build failed and didn't report status. Pretty bad UX, which was happening on test-builds.

[humitos]

I'm going to mark this PR as blocked for now since it will have a big impact and could bring issues to some projects.

[humitos]

This is still a good improvement to reduce our servers load, but we need a smarter "Finish inactive builds" first. I experimented with this at #8269

[humitos]

@ericholscher

I feel like without being able to cancel a build, you can get stuck in a state where it's getting deduped but the build failed and didn't report status

We had implemented the ability to cancel a build now. Should we solve the conflicts and try to move forward with this PR now? The first test would be to re-enable DEDUPLICATE_BUILDS for all projects again. If that works, we can recover this PR.

[ericholscher]

@humitos yep. Thought we did hit some issues with cancelling builds not actually cancelling them in the UX, which made users struggle with their concurrency limit.

[humitos]

Today, while taking a look at #8961I checked if the DEDUPLICATE_BUILDS feature was enabled, and it seems we had enabled it for a long time now. So, I think we can recover this PR, solve the conflicts and merge it, probably.

I think this is currently working fine because we added the condition that only applies to builds triggered 5 minutes ago only:

readthedocs.org/readthedocs/core/utils/__init__.py

Lines 136 to 142 in 877c3ba

	# By filtering for builds triggered in the previous 5 minutes we
	# avoid false positives for builds that failed for any reason and
	# didn't update their state, ending up on blocked builds for that
	# version (all the builds are marked as DUPLICATED in that case).
	# Adding this date condition, we reduce the risk of hitting this
	# problem to 5 minutes only.
	date__gte=timezone.now() - datetime.timedelta(minutes=5),

[humitos]

This PR won't probably be needed if we move forward with #9549 😄