Errors with --server --json fail silently

[bmah888]

NOTE: The iperf3 issue tracker is for registering bugs, enhancement
requests, or submissions of code. It is not a means for asking
questions about building or using iperf3. Those are best directed
towards the iperf3 mailing list at iperf-dev@googlegroups.com or
question sites such as Stack Overflow
(http://www.stackoverflow.com/). A list of frequently-asked questions
regarding iperf3 can be found at http://software.es.net/iperf/faq.html.

Context

• Version of iperf3: 3.9+

• Hardware: Any

• Operating system (and distribution, if any): Any

• Other relevant information (for example, non-default compilers,
  libraries, cross-compiling, etc.):

Bug Report

• Expected Behavior: Errors with --server --json should be reflected in the JSON output?

• Actual Behavior: Failures seem to result in no server-side JSON output

• Steps to Reproduce

Tested with #1101 active test timeout.

Can also test with iperf3 --server --json --server-bitrate-limit 1g and iperf3 --client ___ --bitrate 10g to force a server side error.

• Possible Solution

Maybe need some code like this somewhere, like maybe in some exit path(s) from iperf_run_server() or maybe after the call to iperf_err() below the call to iperf_run_server() in run():

                    if (test->json_output) {
                        if (iperf_json_finish(test) < 0)
                            return -1;
                    }
                    iflush(test);

[bmah888]

Bit of state-saving: I tried the above change. It works in that we get JSON output on the server side even if there are error conditions. The problem now is that there are error paths on the server side where we explicitly write an error string using iperf_err() but also set a value for i_errno. Both of those cause an "error" member to get written to the JSON structure. Two members with the same key violate the JSON specification.

I have tried only doing the call to iperf_err() if we're not doing JSON output, which basically works, although there are a lot of instances of this and it's going to be hard to test all of them. (The authentication code uses this pattern to write out error strings from OpenSSL.)

[bmah888]

More state: It turns out the remaining "lot of instances" are actually all outside the run() call in main.c, which is where the printing of more than one error message can happen. It's possible the work done so far (and committed on the issue-1118 branch) is actually satisfactory.