Fix incorrect logic in serverHealthInfo

[anjalshireesh]

It was being assumed that whole response has been received as soon as info.Version is non-empty. This is wrong as the very first response by minio contains the version. So removed the unnecessary for loop that had this check to ensure that the whole report is received properly.

[ramondeklein]

The HealthInfoHandler uses a channel and go-routines. The healthInfo object always seems to include the version, so this seems to be safe and do the same thing as before. No need to loop...

During reviewing, I did start to wonder the functionality of this function. It doesn't make much sense to get the health version number on its own. It looks like this method sends data in parts, so we won't get much information here. It only will return the partial information of the first go-routine that completes. Does this need more investigation?

[anjalshireesh]

The HealthInfoHandler uses a channel and go-routines. The healthInfo object always seems to include the version, so this seems to be safe and do the same thing as before. No need to loop...

During reviewing, I did start to wonder the functionality of this function. It doesn't make much sense to get the health version number on its own. It looks like this method sends data in parts, so we won't get much information here. It only will return the partial information of the first go-routine that completes. Does this need more investigation?

@ramondeklein

The server returns the data in multiple iterations, but not incrementally. The same top level structure keeps getting filled with more data in each iteration (including data from previous iterations) - so what we receive in the last iteration is the complete data (first iteration will have almost no data - just two fields - deployment id and the version). I think the original reason behind this is to be able to show progress of report generation on mc. Something like:

❯ ./mc support diag eos-minio1 --airgap --insecure
● CPU Info ... ✔ 
● Disk Info ... ✔ 
● Net Info ... ✔ 
● OS Info ... ✔ 
● Mem Info ... ✔ 
● Process Info ... ✔ 
● Server Config ... ✔ 
● System Errors ... ✔ 
● System Services ... ✔ 
● System Config ... ✔ 
● Admin Info ... ✔ 
*********************************************************************************
                                   WARNING!!
     ** THIS FILE MAY CONTAIN SENSITIVE INFORMATION ABOUT YOUR ENVIRONMENT **
     ** PLEASE INSPECT CONTENTS BEFORE SHARING IT ON ANY PUBLIC FORUM **
*********************************************************************************
mc: MinIO diagnostics report saved at  eos-minio1-health_20240926040720.json.gz

The report format has changed over a period of time, so the version number serves two purposes:

• helps mc to figure out what data has already been received and what is under process, using version specific logic
• helps subnet to parse and analyze the report correctly

Here, since the purpose is to simply fetch the report and not process it in any way, the version number can be ignored, and we can also ignore initial responses from minio and wait for all data to be received before returning it to the frontend.