Change default behavior for missing output

[brynary]

Prior to this PR, if a linter exited with a success exit code but did not produce any output, we would hand an empty string to the parser. In substantially all situations, this will result in a confusing EOF error from the parser, because it will try to e.g. parse an empty string as JSON.

This PR changes the default -- If a linter exits with a success exit code, but does not produce output, we will treat that as a Lint Error and skip the parser phase entirely.

This behavior can be overridden by two alternative behaviors: parse or no_issues. parse will invoke the parser with an empty string, and no_issues will treat the empty output as if it produced output along the lines of issues = []

(Previously, we had a missing_output_as_error boolean. The new output_missing enum replaces that.)

[qltysh]

The code coverage on the diff in this pull request is 73.5%

Drilldown

Path	File Coverage Δ
qlty-check/src/executor/driver.rs *	-0.9
qlty-check/src/executor/invocation_result.rs	0.6
qlty-check/src/tool/command_builder.rs *	2.6
qlty-check/src/tool/download.rs *	0.7
qlty-check/src/tool/ruby/sys/linux.rs *	-1.6
qlty-check/src/tool/ruby/sys/macos.rs *	3.1
qlty-cli/src/initializer/scanner/gemfile.rs *	0.3
qlty-cloud/src/auth/auth_flow.rs *	-0.5
qlty-config/src/library.rs *	0.5

[qltysh]

The code coverage on the diff in this pull request is 73.5%

Drilldown

Path	File Coverage Δ
qlty-check/src/executor/invocation_result.rs	0.6
qlty-config/src/library.rs *	0.5

[qltysh]

1 new issue

Tool	Category	Rule	Count
qlty	Structure	High total complexity (count = 54)	1

qlty successfully analyzed this pull request in 4m.