beegfs health bundle reports success even when the tarball is silently truncated/corrupt

[Willard84]

In bundle.go, bundleSupportFiles() finalizes the gzip/tar writers with deferred, unchecked Close() calls; for example

          gzipWriter *gzip.Writer := gzip.NewWriter(w: tarGzFile)
          defer gzipWriter.Close()

          tarWriter *tar.Writer := tar.NewWriter(w: gzipWriter)
          defer tarWriter.Close()

My understanding is that Close() will write the data to disk, but if something happens during that write (ENOSPACE?), we won't surface it as an error. So a customer (or service) could think they have generated good debug data for development, but when we look at it later the tarball could be corrupt and we'd need to ask them for more data.

I think instead we should explicitly check error codes on Close().