Use payment delay for offset if no start_secs is specified

[carlaKC]

For defined activity, if we do not have start_secs set all of our payments will fire immediately on startup and thereafter run at regular intervals. Eg, if we have payments A running every 5 seconds and payment B every 10 seconds our payment dispatch will be:

• 0 seconds: send A and B
• 5 seconds: send A
• 10 seconds: send B

This seems like undesirable behavior when the start_secs field isn't set in our simulation file. Ideally, we'd distinguish between:

• start_secs: 0 in sim file: fire the payment immediately
• No start_secs in sim file: only fire the payment after its desired interval

So, using the example above when no start_secs is specified our payment dispatch should be:

• 0 seconds: no payments
• 5 seconds: send A
• 10 seconds: send B

This also impacts randomly generated payments - on startup all random payments will fire, then we'll take a look at the wait times that's been randomly generated and wait the appropriate amount of time. These should behave similarly to when no start_secs is defined in the sim file for defined behavior.

[carlaKC]

@bjohnson5 does this make sense to you? It's only sort of a bug because this is the start_secs field working as intended (firing after 0 seconds), but I think this approach is a good in between.

[bjohnson5]

@carlaKC Yes, I think this makes a lot of sense. I can see that if a user does not specify a start time they would be surprised that any payments have gone out before the first interval time. I will take a look at the PR!