Fix #91

[andreleblanc11]

See #91 (comment) on the most recent analysis done regarding this issue.

Sometimes in the restart_server flow test the watch will miss posting 1 or more files due to the timing of the sr3 restart being done.

If we touch all the files after the last restart, this should assure all files get posted downstream due to the watchdog noticing them if ever any are missed.

I also don't think this is a problem in the watch code due to the nature of how the watchdog works.

I ran the restart_server flow test without the patch 3 times and it only passed 1/3 times.
I ran the restart_server flow test WITH the patch 5 times and it passed 5/5 times.

All of these runs were on a RHEL8 machine as it seemed to be the environment to trigger the problem the most often. This problem also occurs on the GitHub action runs.

[reidsunderland]

This is interesting, but the watch config has post_on_start enabled, so it should be posting all files that exist in it's watched directory once it starts up. Maybe that's not working properly? Or the watch is getting far enough to store the file in it's nodupe cache but not post it?

[petersilva]

This is a weird fix. the whole point of the restart_server test is to confirm that it doesn't lose any posts across restarts. If you have to touch files after each start... well that means it isn't working and should not pass, no?

[andreleblanc11]

You are right. I didn't look long enough into the problem and forgot about post_on_start being a thing. I will close this PR. I'm also making a comment in the issue about my recent findings.