Add closed timestamps to the architecture docs

[rmloveland]

Currently, the only place where we mention closed timestamps is on the Follower Reads page (AFAICT).

We should find out where they live in the architecture and document them there as well.

[rmloveland]

From a comment by @ajwerner on #6801:

This is a bit down in the weeds but a question that has come up before is where does this 4.8 seconds number come from. The answer is due to some cluster settings which we don't make public because we don't think they're easy to use. I'm going to explain how it works here and you can do with it what you will (which could very reasonably be nothing).

The answer is that it comes from the closed timestamp target duration and some other setting. The closed timestamp subsystem effectively makes history immutable. We have it do this periodically. The duration in the past we "close out" is controlled by kv.closed_timestamp.target_duration. We do this every kv.closed_timestamp.close_fraction of the duration. We want to have a high chance of actually hitting a follower read so we want some number of these fractional intervals for the closure to likely propagate.

> SELECT * FROM [SHOW ALL CLUSTER SETTINGS] WHERE variable LIKE '%closed%' OR variable LIKE '%follower%'; 
                        variable                  | value | setting_type | public |                                                                                                                                           description                                           
     ---------------------------------------------+-------+--------------+--------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
       kv.closed_timestamp.close_fraction         | 0.2   | f            | false  | fraction of closed timestamp target duration specifying how frequently the closed timestamp is advanced                                                                                         
       kv.closed_timestamp.follower_reads_enabled | true  | b            |  true  | allow (all) replicas to serve consistent historical reads based on closed timestamp information                                                                                                 
       kv.closed_timestamp.target_duration        | 3s    | d            | false  | if nonzero, attempt to provide closed timestamp notifications for timestamps trailing cluster time by approximately this duration                                                               
       kv.follower_read.target_multiple           | 3     | f            | false  | if above 1, encourages the distsender to perform a read against the closest replica if a request is older than kv.closed_timestamp.target_duration * (1 + kv.closed_timestamp.close_fraction * this) less a clock uncertainty interval. This value also is used to create follower_timestamp().

[nvanbenschoten]

I stumbled upon this gap in our architecture docs while reading through it. It seems like a nice thing to add when we find the time. As we expand the uses of follower reads (including all reads on GLOBAL tables), closed timestamps will play an increasingly important role in our architecture.