update: print JSON version output by using json_output config field

[jasondellaluce]

What type of PR is this?

/kind cleanup

/kind feature

Any specific area of the project related to this PR?

/area engine

/area tests

What this PR does / why we need it:

This PR proposes removing the recently-introduced version-json CLI option and makes Falco print a JSON version output depending on the json_output configuration field such as follows:

# userspace/falco/falco --version 
Falco version: 0.33.1-111+faa878d
Libs version:  0.10.0
Plugin API:    2.0.0
Engine:        15
Driver:
  API version:    3.0.0
  Schema version: 3.0.0
  Default driver: 4.0.0+driver

# userspace/falco/falco --version -o json_output=true
{"default_driver_version":"4.0.0+driver","driver_api_version":"3.0.0","driver_schema_version":"2.0.0","engine_version":"15","falco_version":"0.33.1-111+faa878d","libs_version":"0.10.0","plugin_api_version":"2.0.0"}

The goal here is to avoid duplication of UX elements, since json_output is already used other Falco features to control whether the output is in plain text of JSON format.

Which issue(s) this PR fixes:

Special notes for your reviewer:

This PR can be the first of a series where we make every Falco output support a JSON format depending on the json_output configuration. In the past, that field was only used to control the JSON formatting of the alert outputs, and it recently was also used to output the result of rule files validation in JSON format. Since we now have a third use case, I think in the future we might use json_output to make every Falco output formatted as JSON and thus machine-readable.

Also, this PR refactors a little bit the falco_configuration class (responsible of ~250 LOC to preserve the git blame), which can not be initialized and supports a more explicit default state. Moreover, loading the configuration has been moved as the first action performed by Falco, so that all actions can rely on configuration fields (such as json_output). Accordingly, blocking validation checks (such as requiring at least one enabled output or at least one rules file) are moved in their own action, so that early actions such as print_version are not blocked and can proceed even with an empty configuration.

Does this PR introduce a user-facing change?:

update: print JSON version output when json_output is enabled

[jasondellaluce]

/milestone 0.34.0

[FedeDP]

Minor comments/questions aside, LGTM!

[FedeDP]

Perhaps @LucaGuerra is interested, because he made the version-json change ;)

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: a2a250a200f96d737b0ec0a5f650b234c7aedab8

[Andreagit97]

/approve

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP, jasondellaluce

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Andreagit97,FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[happy-dude]

Can there be an additional documentation update that makes it clear that json_output influences the --version flag? ref: https://falco.org/docs/reference/daemon/config-options/

This was surprising to me initially when pulling in the latest upstream changes because I expected json_output to only influence the output of the falco_events / alerts / logs; I did not expect this option to influence the output of --version.

(My confusion was also compounded a user runs falco --version and doesn't have permissions to read /etc/falco/falco.yaml, so their output appeared as what I was familiar with whereas a script executing w/ the right context/permissions had the output in JSON.)