Add future default true to Feature flags

[ericholscher]

This also renames default_true to past_default_true,
making it more explicit as to which does which.

This will give us a lot more flexibility with feature flags,
since we often want to have one of these options with them.

[ericholscher]

This didn't rename the field, will need to fix that :(

[humitos]

I think this is super handy!

I know that @stsewd were doing multiple migrations when deleting fields to avoid breaking on deploy. We may need to do the same here since we are renaming a field, so old instances will try to hit the old name.

[humitos]

This looks unrelated here. I don't know where this came from... 😕

[stsewd]

yeah, this is going to break during deploy. We should do something like:

During a first deploy

• create the new fields, don't delete the old one (make it nullable here)
• Run a data migration from the data of the old field to the new field (we shouldn't create new feature flags with default=true during this time, or make the data migration during the second deploy)

During a second deploy

• Replace the usage of the old field with the new field
• Delete the old field

[humitos]

Once this gets merged and deployed, I'd like to mark future_default_true=True to the following feature flags and update its add_date accordingly:

• LIMIT_CONCURRENT_BUILDS
• DEDUPLICATE_BUILDS
• SPHINX_PARALLEL (edit): we can't enable this yet because we are not installing latest readthedocs-sphinx-extension by default and it's not parallel safe, which makes everybody using fail_on_warning=True to fail the build.
• VCS_REMOTE_LISTING

BTW, using the add_date (creation date) to compare which projects are going to be affected by the feature flag may end up with "invalid" datetime if it's updated. We are using the same datetime for two different things: "creation date of the object" and "date the feature start taking effect". If we want to keep those different dates, we should add a different field into the model.

[ericholscher]

Alright, I updated this PR to not change the existing model. I think it's fine for now, and we can adjust in the future if we need to.

[ericholscher]

BTW, using the add_date (creation date) to compare which projects are going to be affected by the feature flag may end up with "invalid" datetime if it's updated. We are using the same datetime for two different things: "creation date of the object" and "date the feature start taking effect". If we want to keep those different dates, we should add a different field into the model.

Agreed. We should probably add a date field and use that, but I think the created date will never be automatically updated, so I don't think it's a huge issue.

[humitos]

We should probably add a date field and use that, but I think the created date will never be automatically updated, so I don't think it's a huge issue.

It's not because it will be updated automatically, just that when we changed it manually we loose the original date that feature was created. For example, after today's deploy I want every new project to use a feature that already existed, so I will change the created date and loose the original one.

[ericholscher]

Ah, I see what you mean. Do we care about the actual created date on the model?

[humitos]

I don't think it's important, but it's a nice to have to me.