Nameservice, Scheduler: Jitter-option can postpone actions a *very* long time

[Akira25]

At Freifunk Berlin we had some issue with the scheduler of OLSRd in conjunction with the nameservice plugin. In result, We've seen the bug, that on some nodes there wasn't updates to the services-file for a very long time.

For convenience, I am going to cite from our downstram issue:

Actually we found out, that due to a programming error, file-write-option has nearly no effect on the daemon writing data, even if it changed. There's need for one change in the olsrd-code, which you can see here:
#114

Basically the amendment of jitter in the scheduler call made OLSR to add an amount of seconds to the intervall of 5 seconds. These amount can range from 0 to INT_MAX. If we get INT_MAX or something a bit below that value, it can take days until olsrd will write the next update to the file. Thus we made that PR. But before going into upstreams master-branch we wanted to test it further.

olsrd/src/scheduler.c

Lines 601 to 622 in 1e771b4

	calc_jitter(unsigned int rel_time, uint8_t jitter_pct, unsigned int random_val)
	{
	unsigned int jitter_time;
	/*
	* No jitter or, jitter larger than 99% does not make sense.
	* Also protect against overflows resulting from > 25 bit timers.
	*/
	if (jitter_pct == 0 || jitter_pct > 99 || rel_time > (1u << 24)) {
	return GET_TIMESTAMP(rel_time);
	}
	/*
	* Play some tricks to avoid overflows with integer arithmetic.
	*/
	jitter_time = (jitter_pct * rel_time) / 100;
	jitter_time = random_val / (1 + OLSR_RANDOM_MAX / (jitter_time + 1));
	OLSR_PRINTF(3, "TIMER: jitter %u%% rel_time %ums to %ums\n", jitter_pct, rel_time, rel_time - jitter_time);
	return GET_TIMESTAMP(rel_time - jitter_time);
	}

Unfortunately we didn't come to test the change until now, as it involves packaging and installing OLSRd in a custom version on one of out nodes.

Help with testing this change is highly appreciated! (See #114)