Removed current_instance_checks from docs. (#18186)

#16661 

Removed current_instance_checks from docs.

docs/Configuration/configuration-files/README.md

@@ -445,7 +445,7 @@ spec:
     cpe_database_url: ""
     cpe_translations_url: ""
     cve_feed_prefix_url: ""
-    current_instance_checks: "auto"
+    disable_schedule: false
     disable_data_sync: false
     recent_vulnerability_max_age: 30d
     disable_win_os_vulnerabilities: false

docs/Configuration/fleet-server-configuration.md

@@ -2275,7 +2275,7 @@ If set then `fleet serve` will run even if there are database migrations missing
 
 The path specified needs to exist and Fleet needs to be able to read and write to and from it. This is the only mandatory configuration needed for vulnerability processing to work.
 
-When `current_instance_checks` is set to `auto` (the default), Fleet instances will try to create the `databases_path` if it doesn't exist.
+When `disable_schedule` is set to `false` (the default), Fleet instances will try to create the `databases_path` if it doesn't exist.
 
 - Default value: `/tmp/vulndbs`
 - Environment variable: `FLEET_VULNERABILITIES_DATABASES_PATH`
@@ -2345,21 +2345,11 @@ When not defined, Fleet downloads CVE information from the nvd.nist.gov host usi
     cve_feed_prefix_url: ""
   ```
 
-##### current_instance_checks
-
-When running multiple instances of the Fleet server, by default, one of them dynamically takes the lead in vulnerability processing. This lead can change over time. Some Fleet users want to be able to define which deployment is doing this checking. If you wish to do this, you'll need to deploy your Fleet instances with this set explicitly to no and one of them set to yes.
-
-- Default value: `auto`
-- Environment variable: `FLEET_VULNERABILITIES_CURRENT_INSTANCE_CHECKS`
-- Config file format:
-  ```yaml
-  vulnerabilities:
-    current_instance_checks: yes
-  ```
-
 ##### disable_schedule
 
-To externally manage running vulnerability processing set the value to `true` and then run `fleet vuln_processing` using external
+When running multiple instances of the Fleet server, by default, one of them dynamically takes the lead in vulnerability processing. This lead can change over time. Some Fleet users want to be able to define which deployment is doing this checking. If you wish to do this, you'll need to deploy your Fleet instances with this set explicitly to `true` and one of them set to `false`.
+
+Similarly, to externally manage running vulnerability processing, set the value to `true` for all Fleet instances and then run `fleet vuln_processing` using external
 tools like crontab.
 
 - Default value: `false`

docs/REST API/rest-api.md

@@ -1029,7 +1029,7 @@ None.
   },
   "vulnerabilities": {
     "cpe_database_url": "",
-    "current_instance_checks": "auto",
+    "disable_schedule": false,
     "cve_feed_prefix_url": "",
     "databases_path": "",
     "disable_data_sync": false,

docs/Using Fleet/Vulnerability-Processing.md

@@ -76,7 +76,7 @@ The reasons for this are as follows:
 - more control over scheduling constraints (only process during windows of low utilization, etc.)
 
 It is possible to limit vulnerability processing to a single [dedicated host](https://fleetdm.com/docs/deploying/configuration#current-instance-checks), by setting
-`current_instance_checks` to `no` but still run one Fleet server as `yes`, but the drawback here is still having to dedicate resources
+`disable_schedule` to `true` but still run one Fleet server as `false`, but the drawback here is still having to dedicate resources
 for this single host 24/7. The Fleet binary has a command which handles the same vulnerability processing, but will exit (successfully with 0) on completion. Using this sub-command we can delegate vulnerability processing
 to external systems such as: