Toggling an issue task item checkbox updates the whole description, possibly reverting other changes

The recent move to a Rust-based parser for tasklists (Use Rust-based parser for tasklist parsing (!212709 - merged)) appeared to have caused some odd regressions — see Task lists not rendering consistently? Task lis... (#582349 - closed).

In fact, one was a render timeout (from well before the change was deployed), and the other was a consequence of how task item updates appear to be done in the work item view for issues.

We have a TaskListToggleService which quite efficiently and safely updates a task item's status in the Markdown source and rendered HTML, which I think is still used in many places. It is not used in the work item view for issues, however: instead, we issue a workItemUpdate GraphQL mutation, sending the entire updated description along.

This opens the door to race conditions where updates revert changes made by other users if their browser tab doesn't have the latest version of the description for whatever reason. It happened rather a lot on that one issue, possibly reflecting increased backend load resulting in more dropped Action Cable connections.

Investigate where these updates are issued and how hard it'd be to instead update the task item using a similar locator to the update_task/TaskListToggleService machinery.