Added command line option for starting client on a uniform interval

[oleorhagen]

With the option -startup_interval the client will, in the case of pregenerated
keys, spread the client startups evenly out on an interval of time designated
by this configuration option. This helps in scale testing, as all clients will
not come online at the same time, and hence bring the server to its knees.

Changelog: Title

Signed-off-by: Ole Petter ole.orhagen@northern.tech

[lluiscampos]

The change itself LGTM.

The only detail I see is that now we will have one parameter in seconds, while the rest are all in millis. We should leave it as it is, of course, not to break any of current Scale testing scripts, but for next round it would be nice to be consistent.

@0lmi Please note that startup_interval is in seconds, in case you need to update your scripts. Also, the CI/CD for this repo is finished, so after this PR is merged the docker master image should be automatically updated.

[oleorhagen]

Doesn't this mean that now all the parameters are in seconds though?

The change was added to align with the others, and as a response to:

@OlMi's and probably it’s better to change time from millis to secs, so, it’s the same for all params in the slack-chat.

[oleorhagen]

Also, the behaviour is a little weird, in the case that some keys have to be generated, while some are still present. In this case all the clients that can fetch a pre-existing key from keys/ will start up at once, and can in this case bombard the server, like the old functionality did. There is a note for this in the flag description, but it does make for some possibly unexpected behaviour.

As I see it we can do:

1. Start up the clients with on an interval, just like before, and let the generation of keys be the implicit sleep for the remaining clients without a key.

2. Sleep in both cases, and just let the key-generation add a little bit more randomness to the startup-times.

3. Leave it as it is

[lluiscampos]

Doesn't this mean that now all the parameters are in seconds though?

The change was added to align with the others, and as a response to:

@OlMi's and probably it’s better to change time from millis to secs, so, it’s the same for all params in the slack-chat.

You are right! My miss-understanding, sorry.

[lluiscampos]

2\. Sleep in both cases, and just let the key-generation add a little bit more randomness to the startup-times.

I vote for this.