Make test_launch_ipfs_daemon and pollEndpoint more reliable

[schomatis]

Checklist

• My issue is specific & actionable. #8312
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

Spawned from #8131. In that test (it is likely that) the daemon was not running when it was supposed to and we caught it by chance just because there was a slight change in the behavior of a specific command that made the test fail. (Not sure if in that case the daemon failed/crashed at some point or didn't start altogether.)

We should review the pollEndpoint command and add some tests if possible. Additionally it would be useful to leave some check (pollEndpoint or other) running in the background during sharness tests and periodically check that the daemon is running.

---

Somewhat related to this (but should have its own issue if valuable): As an additional measure the command should be able to tell when it is intending to work through the daemon or not.

Right now we have the NoRemote/NoLocal flags at the command level (in the go-ipfs-cmds/command.go library) but we might want more granularity than that. For example in the above test the --flush=false option in ipfs files write should turn that command into a NoLocal one (to make sure we don't close and flush the local MFS root in the IPFS instance).

Maybe this requirement is too specific to this command alone and in that case just doing an independent check inside the command itself to make sure the daemon is running before executing might be enough.

[schomatis]

Some loose working notes to be incorporated later:

• How do we know the go-ipfs daemon is running at the go-ipfs-cmds level? We check for the api file and dial that (we have access to the repo).

• In the sharness tests we parse the daemon output that we just instantiated and get the address from there (we have direct access to the daemon). We still wait for the api file to be created before dialing but we don't use its content.

[schomatis]

Closing this in favor of more specific actionable items like:

• fix(sharness): add extra check in flush=false in files write #8432
• Allow NoRemote/NoLocal to be configured on a per-run basis go-ipfs-cmds#218

From my review of the sharness test it seems that adding some concurrent check for the daemon to be up in parallel with the running tests in bash is a very involved task and it doesn't seem to have high value at the moment (this should be revisited if we hit more flaky tests like #8131).