Prevent task events manager logging the same message more than once

[wxtim]

Closes #5526

Deals with a bug was returning every message ever sent by a task on each poll.

(Draft pending further checks, to ensure that I haven't broken anything)

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included
• CHANGES.md entry included if this is a change that can affect users
• Update docs - this is a change to Cylc's logging.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[MetRonnie]

This is about more than just preventing duplicate logging. With your branch I still get duplicates in the UI

[wxtim]

@MetRonnie - I think that I fixed it.

[wxtim]

The original approach (adding messages to the activity log file and checking for them later seemed to break some of the workflow restart tests in ways that make me un-confident that they are safe changes.

Scraping the log is horrible.

Next thing to try: using the database - this isn't straightforward, because the database doesn't contain a table which would easily contain the task messages.

[MetRonnie]

Did some playing about with the UI

1. Ran a workflow with a long-running task that does cylc message first thing
2. Stopped the workflow with --now
3. Restarted the workflow

The chip with the message did not appear on restart, whereas before it used to appear with "(polled)" appended

[wxtim]

Update: closed that as it does not seem feasible without a major refactor

Not entirely surprised, but thank you for attempting it.

[MetRonnie]

Got some suggestions for the tests and then I think this is good to go!

[wxtim]

@oliver-sanders are you waiting on me to do something with this?

[oliver-sanders]

Kinda, but I need to take a closer look. I think this isn't skipping enough of the method, the problem is about more than just logging, e.g. it appears to running event handlers and spawning logic for duplicate messages? But I know that when you tried moving the return higher up the function it caused problems.

[wxtim]

I've had another look at this recently, and the notes on Matt Shin's original logic says

       # Unhandled messages. These include:
       #  * general non-output/progress messages
       #  * poll messages that repeat previous results
       # Note that all messages are logged already at the top.

https://github.com/cylc/cylc-flow/pull/2157/files

So it looks like Matt intended to have it work more simply than this and it's broken at some point. I'm going to reexamine this. :)