Add commandline option constraints

Description

When poking around, I noticed that certain options that should only allow positive values (such as --genesis-time and --validator-count in teku genesis mock) will process negative values.

For negative genesis times, the checkArgument call will catch the problem and throw an exception.

$ teku genesis mock --genesis-time -1
java.lang.IllegalArgumentException: value (-1) must be >= 0
  <call stack>

But for most other options, it will continue as normal. For example, a negative validator count will not show any warnings. In this situation, validatorCount is effectively zero because IntStream.range(0, -1) is a range of zero. So it’s not really a problem here.

Below are some other options that could benefit from constraints. I’m able to specify negative values for all of them.

--eth1-deposit-contract-max-request-size=<INTEGER>
--metrics-port=<INTEGER>
--p2p-advertised-port=<INTEGER>
--p2p-advertised-udp-port=<INTEGER>
--p2p-peer-lower-bound=<INTEGER>
--p2p-peer-upper-bound=<INTEGER>
--p2p-port=<INTEGER>
--p2p-udp-port=<INTEGER>
--rest-api-port=<INTEGER>
--validators-external-signer-timeout=<INTEGER>
--data-storage-archive-frequency=<FREQUENCY>
--number=<arg1>

Possible Solution

Add validation constraints to some picocli options. Here is an example:

• https://picocli.info/#_jsr_380_beanvalidation

This would look like:

@Min(value = 0, message = "Genesis time must be a positive value")
@Option(
    names = {"-t", "--genesis-time"},
    paramLabel = "<GENESIS_TIME>",
    description = "The genesis time")
private long genesisTime = System.currentTimeMillis() / 1000;

Note, another project dependency would be required.

implementation group: 'javax.validation', name: 'validation-api', version: '2.0.1.Final'

I would be happy to do this and submit a pull request if it’s something we want to fix.

[jtraglia]

@ajsutton I can shave some yaks if you want. I don’t think :infrastructure:exceptions should have that dependency either. Also, I started a PR just to get the ball rolling. It doesn’t allow those options I mention in the issue to have negative values anymore. I also added validation checks to some other options too. I’m not sure if I should add more checks elsewhere or not. To my surprise, throwing IllegalArgumentException doesn’t print a stack trace and doesn’t look that bad, but I’m still planning on changing all of to InvalidConfigurationException exceptions.

[ajsutton]

To my surprise, throwing IllegalArgumentException doesn’t print a stack trace and doesn’t look that bad, but I’m still planning on changing all of to InvalidConfigurationException exceptions.

Yeah we must have special handling for IllegalArgumentException when parsing the options but definitely nicer to use the more specific exception type.

Just left a comment on the PR as well. It’s looking good - thanks for taking this on.