chore(tests): Disable flaky tests on MacOS

[ktff]

Ref. #2978, #4056

I'll just keep disabling tests for Mac in this PR until we get a consistently passing check, and after that make a triage of them. This to avoid accumulation of broken tests behind a couple, hopefully, of them at moment

Tests disabled on Mac:

• tcp_stream_detects_disconnect
• file_update
• topology tests

[jamtur01]

cc @leebenson

[leebenson]

Even if all tests pass, there's #4196 to contend with. I added some additional commentary to that issue this morning.

I'm not sure how to probe it further, without being able to SSH into an active runner and do some more extensive stack tracing against the compiled binary. I can't recreate this locally at all. I've seen segfaults in other environments where memory pressure was clearly the issue (i.e. actual "out of memory" errors in the console), so possibly this is a memory pressure thing. Not sure. It could also be a genuine segfault due to unsafe code in a lib somewhere, but why then would this only show up in macOS and not my own macOS environment at that, I don't know.

Not sure how to probe this any further without choosing a 'proper' CI where we have more control over the underlying hardware, OS and can SSH into the environment.

[leebenson]

It could also be due to something I've done in GraphQL tests if, like @jszwedko commented, this was indeed introduced in #4187 (although I'm pretty sure I've come across this a time or two before; feels older than a few days.)

[jszwedko]

@leebenson It's a bit hacky, but I've actually used https://github.com/mxschmitt/action-tmate before to get SSH access to a running Github Action job for debugging a similar type of issue that only happens on CI.

[leebenson]

Thanks @jszwedko, I was looking for something like that! Will give it a shot.

[ktff]

@leebenson

Even if all tests pass, there's #4196 to contend with

That sounds like a tough issue. Then I would at least like to either confirm or eliminate the possibility that some smallish subset of tests can cause #4196. It's quite possible that some specific tests are corrupting the memory which then causes SEGFAULTs at random times. Although I'm now aware that this approach in PR may not work.

[ktff]

@leebenson as you reported in #4196 SEGFAULT started to happen after the tests where whole test groups can be the cause, and with recent bors upgrade this isn't viable approach so I'll close the PR.