### Description
Selected algorithm is a hash, over Call-ID, From, etc. If destination is not available, a new one must be selected, without breaking the hash assignation (all messages with the same hash must be forwarded to the same destination)
### Expected behavior
The load to the failed destination to be (hopefully) evenly distributed over the remaining destinations.
#### Actual observed behavior
All the messages that were supposed to be sent to the failed destination are sent to only one of the remaining, causing it to receive double load, comparing with the rest
#### Debugging Data
In this test, 6000 Calls were sent to a group of six destinations, using algorithm "0" (hash over Call-ID)
| All destinations active -- | -- Dest1 | 996 Dest2 | 997 Dest3 | 999 Dest4 | 1006 Dest5 | 1005 Dest6 | 997 Total | 6000

Repeating the test, but with destination Dest4 down:
| OriginalImplementation -- | -- Dest1 | 975 Dest2 | 993 Dest3 | 2022 Dest4 | 0 Dest5 | 1019 Dest6 | 991 Total | 6000

We can see that poor destination Dest3 receives double traffic
### Possible Solutions
I implemented a solution that does not break the expected behavior (messages with same hash are assigned the same destination, but with a better distribution over remaining destinations)
| New Implementation -- | -- Dest1 | 1175 Dest2 | 1206 Dest3 | 1191 Dest4 | 0 Dest5 | 1216 Dest6 | 1212 Total | 6000

Basically, the solution is as simple as to execute a rehash of the original hash.
I will create a pull request with the proposed change, which I already tested, as it can be seen on the previous chart.
### Additional Information
* **Kamailio Version**
``` kamailio 5.4.0-dev4 (x86_64/linux) 0c29e8-dirty ```
* **Operating System**:
``` Linux Rechitsa 5.4.19-100.fc30.x86_64 #1 SMP Tue Feb 11 22:27:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
```
It seems that addresses are loaded in reverse order in dispatcher module. As it can be seen, when Dest4 is down, it's not Dest5 which receives all load. Its Dest3. In the code it's clear that id is incremented by one, not decremented. Only explanation I see is that order of addresses is loaded in reverse.
Also, when we activate the flag "use_default", which, according to the documentation :
_3.10. use_default (int) If the parameter is set to 1, the last address in destination set is used as a final option to send the request to._
It's not the last address the one reserved and that doesn't receive traffic in normal conditions.
**It's the first one!**
As discussed in #2363, this is by design, and changing the behaviour is not fixing an issue, but an new feature/enhancement.
The evolution can be tracked on #2363.
Closed #2361.