Prevent excessive reply times in the Query Log after restarting

[DL6ER]

By submitting this pull request, I confirm the following:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10

---

The query->reply_time variable serves two purposes: (1) When sending a query upstream, we store the current time in this field. (2) When the reply arrives, we compute the difference and store it in the same field. We memorize the transition from (1) to (2) by setting the flag query->flags.response_calculated to true.

Currently (broken in development, not in master), we store the reply_time field unconditionally, hence, for a few queries which are still being processed upstream at restart, we store the real time instead of the response. FTL incorrectly interprets the (homogeneous!) timestamp as difference and telly you the query needed quadrillions of milliseconds to get answered.

We fix this small bug by instead storing NULL in the REPLY_TIME column when the reply time is not available. FTL already handles this case well when loading from the database: the default of query->flags.response_calculated is false. A NULL value in this field does not change this default.

[DL6ER]

No documentation change is required. The current documentation already says that the field is allowed to by "empty" which means NULL for SQL with column type REAL.

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-ftl-v5-14-web-v5-11-and-core-v5-9-released/53529/1