ike: Properly support high number of retransmission tries

ike: Properly support high number of retransmission tries

Due to the exponential backoff a high number of retransmits only
makes sense if retransmit_limit is set.  However, even with that there
was a problem.

We first calculated the timeout for the next retransmit and only then
compared that to the configured limit.  Depending on the configured
base and timeout the calculation overflowed the range of uint32_t after
a relatively low number of retransmits (with the default values after 23)
causing the timeout to first get lower (on a high level) before constantly
resulting in 0 (with the default settings after 60 retransmits).

Since that's obviously lower than any configured limit, all remaining
retransmits were then sent without any delay, causing a lot of concurrent
messages if the number of retransmits was high.

This change determines the maximum number of retransmits until an
overflow occurs based on the configuration and defaults to UINT32_MAX
if that value is exceeded.  Note that since the timeout is in milliseconds
UINT32_MAX equals nearly 50 days.

The calculation in task_manager_total_retransmit_timeout() uses a double
variable and the result is in seconds so the maximum number would be higher
there (with the default settings 1205).  However, we want its result to
be based on the actual IKE retransmission behavior.