Fix repeat deletion Issue

[shubham1g5]

Technical Summary

https://dimagi.atlassian.net/browse/USH-4708 (Deleting a repeat was causing errors in resolving references )

After deleting a repeat, a node's reference can change due to change in repeat index of the node. Therefore we need a way to not use the existing cache while resolving references. The way cache is setup today I was not able to find a way to expire it for all nodes without looping through all possible references therefore I choose to pass a flag to not use the cache.

Safety Assurance

Safety story

• Impact should be limited to evaluating Xpath after delete repeats action which already seems to be a little broken at the moment.
• Due to us not using reference cache post delete, there can be a small performance downside after deleting a repeat node for large forms. Although would not expect to be substantial.

Automated test coverage

dimagi/formplayer#1597

QA Plan

None

Special deploy instructions

• This PR can be deployed after merge with no further considerations.

Rollback instructions

• This PR can be reverted after deploy with no further considerations.

Review

• The set of people pinged as reviewers is appropriate for the level of risk of the change.

Duplicate PR

Automatically duplicate this PR as defined in contributing.md.

[shubham1g5]

Closing PR for now as I think I don't have complete picture yet in the problem or solution here. Will reopen once I have more context on the concerned issue.

[shubham1g5]

Closing PR for now as I think I don't have complete picture yet in the problem or solution here. Will reopen once I have more context on the concerned issue.

reopening after verifying some assumptions and tests.

[ctsims]

Hey @shubham1g5

How much work is it to simulate the regression you created in Formplayer directly in this repo? I've found that it's really, really helpful to be able to simulate the direct code path during testing (especially with future regression), but if it's a ton of work not a strong need.

More pressing, I think this is a pretty big change to the interface and the degree of complexity of the lookups, which worries me. I'd be very heavily inclined to follow the alternate path of clearing the reference caches directly by creating a clearVolatiles() (or something similar with a scope that's one level up) method on AbstractTreeElement and propagating that via a walk on the tree for the root which I think constrains the scope more effectively.

[shubham1g5]

Thanks for the feedback, I raised an alternate PR here which should address both these points of feedback #1417 .