Currently the driver has two mechanisms for tracking last scan time on a server:

• Server#last_scan is documented as the start time of the most recent scan.
• Description#last_update_time is documented as the "time the server was last checked".

The description attribute is required by the SDAM spec, and what "last checked" means can actually be one of the following three things:

• When last scan started
• When last scan succeeded
• When the description in question was created

The name of "last_update_time" suggests #3 but the description ("last checked") suggests #2, creating a confusing situation.

The driver internally uses these attributes as follows:

• Server#last_scan is used for throttling monitoring ismaster calls, and for determining staleness in server selection.
• Description#last_update_time is used in cluster constructor to wait for the first round of SDAM.

There are problem in both of these uses:

• Server#last_scan can be nil, until the monitor begins a scan.
• Description#last_update_time is initialized prior to a server being scanned. This causes problems when waiting for the first round of SDAM in the case when the seed is removed from topology - the first round does not wait for nodes discovered from the seed to be scanned.

New proposed implementation:

• Description#last_update_time will retain its implementation of always being initialized when a description is initialized. It therefore reflects the age of the description, not the time when the description's server was scanned. Its docstring will be updated to state this.
• Server#last_scan will change to indicate when the most recent successful scan completed. It will use Description#last_update_time if the description has a non-empty configuration (and thus was obtained from a scan), otherwise the server will fall back to the last scan time tracked by it internally. Code which runs SDAM flow will update the server's @scan_time, which is redundant but always keeps Server#last_scan correct.
• Initial SDAM round will use Server#last_scan, thus waiting for chains of nodes to be discovered.
• Monitoring ismaster throttling will use Server#last_scan with an additional internal variable tracking when the most recent scan started, to ensure throttling in case of repeated manual scan invocations by applications.