Implicitly creating a threshold object in getopts rather than check_threshold

[infraweavers]

Previously, the call to check_threshold would set the threshold on the Monitoring::Plugin object, if thresholds are defined, this means that these 2 snippets have different behaviour:

my $returnCode = $mp->check_threshold($connectionCount);

$mp->add_perfdata(
        label => "OpenVPN clients",
        value => $connectionCount,
        threshold => $mp->threshold
);

$mp->plugin_exit(
        return_code => $returnCode,
        message => $connectionCount . " OpenVPN clients"
);

$mp->add_perfdata(
        label => "OpenVPN clients",
        value => $connectionCount,
        threshold => $mp->threshold
);

$mp->plugin_exit(
        return_code => $mp->check_threshold($connectionCount),
        message => $connectionCount . " OpenVPN clients"
);

To us, this is unexpected. The first snippet, will have thresholds on the perfdata, whereas the second will not. This PR should change the behaviour so that $mp->threshold will exist from as early as possible, so need to run check_threshold before add_perfdata is no longer there.

Open to alternatives if this introduces some behaviour we're not aware of

[sni]

Sounds good. Thanks

[sni]

Let me have a look at the travis tests, they seem unrelated to this PR.

[sni]

could you please rebase this PR, should be fixed with f1e3e73

[infraweavers]

@sni done 👍

[sni]

thanks

[dermoth]

Ok, but what if only one of the threshold is set (warning or critical)? Maybe I'm mistaken but I though that's a valid/common use case (maybe you want to only warn, never go critical...)

[sni]

thats a valid point. It previously checked $self->opts while it now checks critical and warning. This should at least be an or or reverted to the opts check.

[infraweavers]

Yeah sure, we'll switch it to an or

[infraweavers]

@dermoth @sni fix: #23