Avoid invoking non-existent helper for system stats with Crunchy Bridge

[keiko713]

Since we're running selfhosted.GetSystemState with Crunchy Bridge, the test result shows the following a bit confusing message:

	✗ System:              	error running system stats helper process: fork/exec /usr/bin/pganalyze-collector-helper: no such file or directory

This is an expected error as the helper file doesn't exist, but it is alarming, so let's not flag this error with Crunchy.

[msakrejda]

Nice, thanks for fixing this.

I think this approach works (and feel free to merge as-is), but it complicates the existing Crunchy dependency on self-managed (a somewhat dubious idea in the first place), which I think makes the code harder to follow. One thing we could do instead is factor out the shared code and split out the self-managed specific part. E.g., something like

        } else if dbHost == "" || dbHost == "localhost" || dbHost == "127.0.0.1" || config.AlwaysCollectSystemData {
		systemHelperState := selfhosted.GetSystemStateFromHelper(server, logger)
		system = selfhosted.GetSystemState(server, logger, systemHelperState)
	} else {

And the Crunchy code could just pass an empty systemHelperState struct or something. These are terrible names, but I think you get the idea.

[msakrejda]

I also took the liberty of updating the PR title to avoid confusion. Feel free to edit further, of course.

[keiko713]

I think this approach works (and feel free to merge as-is), but it complicates the existing Crunchy dependency on self-managed (a somewhat dubious idea in the first place), which I think makes the code harder to follow. One thing we could do instead is factor out the shared code and split out the self-managed specific part. E.g., something like

Thanks for the idea! I agree that this is really a workaround (well, Crunchy using self managed one is already a workaround). I tried to extract the part that pulls data from a helper, though it didn't really click me (like you noticed, we do need to return systemHelperState (helperStatus), then we need to have a special handling of putting the values of helperStatus to state.SystemState, etc. etc.), so I'll merge this as is.
Also thanks for updating the title!