feat(#9714): remove rules-engine's interval turnover

[kennsippell]

Description

I'm proposing this change based on a) the evidence from #9714 which demonstrates that interval turnover is likely causing incorrect values in target docs, and b) this comment from #9486 which suggests interval turnover is no longer needed. The linked comment also suggests this is maybe not the correct approach, so I'm open to all suggestions.

Removing interval turnover reopens the hole documented via #6209 but it should be significantly smaller after #9486.

#9714

Code review checklist

• UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design.
• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[dianabarsan]

I think interval turnover is still needed for project that upgrade from a version older than 4.13 to 4.13, in case some users end up upgrading after the previous month ended.
Otherwise I think interval turnover is safe to be removed.

[kennsippell]

I'm planning to deploy this in Nairobi and see if the target doc data quality improves in January. I've created FR branch 4-13-FR-no-interval-turnover for this. I'd appreciate a review prior to deploying to confirm I haven't missed anything.

These are the options I see to move this forward in main:

1. Remove interval turnover completely (as proposed)
2. Move interval turnover to be a public interface of RulesEngine. Run it once after upgrade from <4.13.
3. Keep IntervalTurnover and continue deeper down the path to hammer out the problems.

My inclination is toward Option 1 because:

1. The data in target docs is simply untrustworthy today. I agree user's may incur and one-time reduction in accuracy when upgrading to this, but we are kinda breaking something that is already broken.
2. Seems quite rare that a user would sync the change in a manner where they would be impacted.
3. Option 2 requires maintenance forever.
4. I'd discuss Option 3 further after experimenting with this change in January and confirm there is still a significant unaddress measurement gap.

How would you proceed?

[dianabarsan]

I agree with option 1, if we're not worried about projects potentially missing one recalculation after upgrade.

I hope this fixes the data quality, because I not entirely convinced it will. Interval turnover would have saved a snapshot of the last calculation, which now should be accurate. Wrong targets means that the snapshot was wrong already :|

[kennsippell]

Reviewing data from Nairobi, I pulled the # of CHPs who disagreed with their previous month's target data + their supervisor reviewed their previous month's performance and agreed that the data was significantly wrong.

Before this change (November Targets) it was 462 CHPs (6.7%). After (December targets), it was 215 CHPs (3.5%).
Of these, 275 CHPs had all 0s before the change. vs 68 CHPs having all 0s after the change.

So this does seem to result in an improvement. I think this also removes a "layer of spookiness" which makes it easier to remotely debug and understand what might be going on.