Reduce the number of times unix_time_update is called.

[iphydf]

Reduced by, e.g.:

• file_transfer_test: 33% of the clock_gettime calls.
• tox_many_test: 53% of the clock_gettime calls.

Other tests will see similar improvements. Real world applications will
be closer to 40-50% improvement, since tox_many_test has 100 nodes, while
file_transfer_test has 2 nodes.

---

This change is 

[zugz]

What about testing/DHT_test.c?

[zugz]

Shouldn't the time also be updated in testing/DHT_test.c, and in new_onions() in onion_test.c, and in test_add_to_list and test_list_main in auto_tests/dht_test.c?

Is it definitely ok that e.g. the timestamp associated to sending a packet is that of the start of the tox iteration, rather than the time the packet is actually sent?

How are writers of tests like these going to know when they should update the time?

[iphydf]

Fixed DHT_test.c.

Time updates only need to be done when you are going to consume time. The dht tests you mentioned don't do anything related to time. Yes, new_onions may need that temporarily. I think it would make sense to call mono_time_update in mono_time_new so the time starts off being valid and doesn't need initialisation in various places. As for where to update it, that is indeed up to the test author, if they are going to test internals. Most auto-tests should be testing the public api and thus don't need to care about time keeping. It is already true today that test authors need to know when/whether to update times if they work with internals. If they don't know, their test may or may not work depending on where we have the time updates in our internals. This makes tests brittle, and makes internal refactoring harder.