Remove support for running validations during the client-side muting transition

[jkuester]

What feature do you want to improve?

Spinning this out of https://github.com/medic/cht-core/issues/9544 to give it proper attention and consideration (and particularly to get @dianabarsan's thoughts). Also, this is a per-requisite for #9544 and can be shipped ahead of that issue.

TLDR, as a part of #9544 we want to remove the key:value entries from the freetext search indexes to dramatically reduce the storage space used by these indexes on device. The goal of this issue is to remove validations support from webapp because the exists validation function relies on these key:value entries.

When the muting transition executes on Sentinel, it can run a set of configured validations on the muting/un-muting report before actually executing the action. The primary purpose here is to support muting via sms workflows (where you cannot really pre-validate the form data like you can when filling out an Enekto form in webapp).

Describe the improvement you'd like

When client-side muting was introduced into webapp, support was also included to continue running these validations when muting a client-side contact. The arguments for removing this functionality now are:

• For the most part the validations logic should instead be included in the Enekto form to prevent the user from ever submitting an invalid muting/un-muting report.
• The parts of the validations logic that are most difficult to re-create in an Enekto form (e.g. exists) are limited in scope when running offline (since they only have access to the data on the device) and so could produce different results than if the validation was run on the server. (e.g. the exists function does not find anything when running on the device, but could find something when running in Sentinel).

Because of this, and the perceived strong likelihood that no one is relying on validations for their webapp-based muting workflows the benefits of reducing disk usage on the device seem to outweigh the possible downsides of losing validations on client-side muting transitions.

Describe alternatives you've considered

Perhaps it would be possible to trigger the validations to run in Sentinel _for client-side muting/unmuting operations, once the muting reports are replicated to the server. Then maybe the server could roll-back the operation if the report fails the validations.

[mrjones-plip]

two questions:

1. I assume we don't think this is a breaking change per "perceived strong likelihood that no one is relying on validations for their webapp-based muting workflows" ? Conversely, I assume we won't ship this if we find that indeed folks are relying on these validations? (or we'll wait 'til 5.0)
2. Have we quantified the disk savings on handsets? given the scope of this change I wanted to be sure we knew the trade offs of saved space vs invasiveness of the change.