ctclient fails if any unexpected arguments are found

[mhutchinson]

All of the parameterization to the subcommands is performed by flags. However, as the subcommands themselves are selected via normal arguments (no hyphens), this can lead to newcomers (e.g. me) believing that the log to fetch from could also be a bare argument. On something like get-entries, there was no way to know that the logname was ignored. Now, this will explode and the user gets the option to reconsider how they are specifying the parameters.

e.g. go run github.com/google/certificate-transparency-go/client/ctclient@master get-entries submariner --first 35494500 --last 35494590 looks very reasonable and returns data, but it isn't from submariner.

#900

[pav-kv]

This PR looks good, it reduces possibility of shooting oneself in the foot when using the tool.

Separately, we could think of making the interface more intuitive, by using the non-flag args, sort of like you originally tried to use it.

E.g. ./ctclient get-consistency-proof argon2022 100 200 looks more intuitive than ./ctclient get-consistency-proof --log_name=argon2022 --some-flag-that-I-always-forget-the-name-of=100 --another-flag-which-I-dont-remember=200.

[mhutchinson]

Yeah definitely! I think this is the first right step: tighten things up and avoid surprising behaviour. And future work can just make the whole thing feel more natural, without introducing more ambiguity. 👍