dhclient: Keep two clocks

[cperciva]

Summary

Until July 2024, dhclient kept track of time as seconds-since-epoch as
a time_t. This was a problem because (a) we wanted sub-second timeouts
and (b) timeouts didn't always do the right thing if the system clock
changed.

Switching to using CLOCK_MONOTONIC and struct timespec fixed those
issues but introduced a new problem: CLOCK_MONOTONIC values were being
intepreted as seconds-since-epoch and written to the dhclient.leases
file, causing confusion with DHCP leases expiring in early 1970.

Attempt to compromise between these by keeping track of both times;
any type within dhclient which is a time_t now refers to seconds past
the epoch, while any struct timespec value is a CLOCK_MONOTONIC time.

Fixes: f0a38976b01e ("dhclient: Use clock_gettime() instead of time()")
Sponsored by: Amazon

[dch]

LGTM, had to get past an unrelated panic to test this one :/

lease {
  interface "wlan0";
  fixed-address 192.168.2.9;
  next-server 192.168.2.254;
  server-name "mijnmodem";
  option subnet-mask 255.255.255.0;
  option routers 192.168.2.254;
  option domain-name-servers 192.168.2.254;
  option domain-name "home";
  option broadcast-address 192.168.2.255;
  option dhcp-lease-time 1440;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.2.254;
  option dhcp-renewal-time 720;
  option dhcp-rebinding-time 1260;
  option dhcp-client-identifier 1:c4:ff:99:d6:73:b;
  option option-125 0:0:d:e9:1e:4:6:35:30:37:45:35:44:5:a:4a:39:34:35:35:36:35:30:38:30:6:8:56:52:56:39:35:31:37:73;
  renew 6 2025/4/12 21:43:02;
  rebind 6 2025/4/12 21:52:02;
  expire 6 2025/4/12 21:55:02;
}