30001: Fix a race condition in test_dir_handle_get.c

Previously we used time(NULL) to set the Expires: header in our HTTP
responses.  This made the actual contents of that header untestable,
since the unit tests have no good way to override time(), or to see
what time() was at the exact moment of the call to time() in
dircache.c.

This gave us a race in dir_handle_get/status_vote_next_bandwidth,
where the time() call in dircache.c got one value, and the call in
the tests got another value.

I'm applying our regular solution here: using approx_time() so that
the value stays the same between the code and the test.  Since
approx_time() is updated on every event callback, we shouldn't be
losing any accuracy here.

Fixes bug 30001. Bug introduced in fb4a40c32c4a7e5; not in any
released Tor.

changes/bug30001

@@ -0,0 +1,4 @@
+  o Minor features (testing):
+    - Use the approx_time() function when setting the "Expires" header
+      in directory replies, to make them more testable. Needed for
+      ticket 30001.

src/feature/dircache/dircache.c

@@ -124,7 +124,7 @@ write_http_response_header_impl(dir_connection_t *conn, ssize_t length,
                            long cache_lifetime)
 {
   char date[RFC1123_TIME_LEN+1];
-  time_t now = time(NULL);
+  time_t now = approx_time();
   buf_t *buf = buf_new_with_capacity(1024);
 
   tor_assert(conn);

src/test/test_dir_handle_get.c

@@ -2526,7 +2526,7 @@ test_dir_handle_get_status_vote_next_bandwidth(void* data)
 
   /* Check cache lifetime */
   char expbuf[RFC1123_TIME_LEN+1];
-  time_t now = time(NULL);
+  time_t now = approx_time();
   /* BANDWIDTH_CACHE_LIFETIME is defined in dircache.c. */
   format_rfc1123_time(expbuf, (time_t)(now + 30*60));
   char *expires = NULL;