Keep old clients from removing message rate delay

[digitalcircuit]

In short

• Refuse zero message delays in setMessageRateDelay
  • Stops old clients from setting message rate delay to 0.00 s when creating networks
  • Mimics error checking of setMessageRateBurstSize
  • Enforces core-side; Quassel UI already blocks zero values
  • Removing rate limits by setting Unlimited to true still works

Criteria	Rank	Reason
Impact	★★☆ 2/3	User-facing, avoids corrupting custom rate-limit configuration
Risk	★☆☆ 1/3	More log messages with old clients, not accepting valid changes
Intrusiveness	★☆☆ 1/3	Small set of changes, shouldn't interfere with other pull requests

Testing

Steps

1. Start a core running 0.13-git-master
2. Connect with Quassel client 0.12.4
3. Create a new network, save it
4. Connect with Quassel client 0.13-git-master
5. In newer client, check the Network → Connection tab

Results

• Without fix
  • Message delay is set to 0s (shown as 0.01s due to UI limits)
• With fix
  • Message delay is set to 2.2s, the Quassel default

In both cases, custom rate limits aren't used, however this becomes an issue when one first tries to use custom rate-limits. They might assume Quassel has almost no delay between messages by default.

Example

Before - custom rate limit wrongly not set to defaults

After - custom rate limit properly set to defaults

After - core log

Old client creates a new network on a new core

2016-09-21 19:46:07 Debug: Received invalid setMessageRateBurstSize data - message burst size must be non-zero positive, given 0 
2016-09-21 19:46:07 Debug: Received invalid setMessageRateDelay data - message delay must be non-zero positive, given 0