Deprecate docs for min and max_concurrency

Also adds a section on setting the new concurrency option

doc/administration/sidekiq/extra_sidekiq_processes.md

@@ -73,10 +73,51 @@ workload. Typical values range from `5` for highly CPU-bound tasks to `15` or
 higher for mixed low-priority work. A reasonable starting range is `15` to `25`
 for a non-specialized deployment.
 
+The values vary according to the work each specific deployment of Sidekiq does.
+Any other specialized deployments with processes dedicated to specific queues
+should have the concurrency tuned according to:
+
+- The CPU usage of each type of process.
+- The throughput achieved.
+
+Each thread requires a Redis connection, so adding threads may increase Redis
+latency and potentially cause client timeouts. See the
+[Sidekiq documentation about Redis](https://github.com/mperham/sidekiq/wiki/Using-Redis)
+for more details.
+
+#### Manage thread counts with concurrency field
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/439687) in GitLab 16.9.
+
+In GitLab 16.9 and later, you can set the concurrency by setting `concurrency`. This value explicitly sets each process
+with this amount of concurrency.
+
+For example, to set the concurrency to `20`:
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   sidekiq['concurrency'] = 20
+   ```
+
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+<!--- start_remove The following content will be removed on remove_date: '2024-08-16' -->
+
+#### Manage thread counts with `min_concurrency` and `max_concurrency` fields (deprecated)
+
+WARNING:
+The `min_concurrency` and `max_concurrency` settings were deprecated in GitLab 16.9 and are planned
+for removal in 17.0. Use [`concurrency`](#manage-thread-counts-with-concurrency-field) instead.
+
 We only recommend setting explicit concurrency by setting `min_concurrency` and
 `max_concurrency` to the same value. The two distinct settings are kept for
-backwards compatibility reasons, but for more predictable results use the same
-values – otherwise you might run into issues with Sidekiq jobs piling up.
+backward compatibility reasons. For more predictable results, use the same
+values, or you might run into issues with Sidekiq jobs piling up.
 
 For example, to set the concurrency to `20`:
 
@@ -108,16 +149,7 @@ concurrency is set to:
 When `min_concurrency` is greater than `max_concurrency`, it is treated as
 being equal to `max_concurrency`.
 
-The values vary according to the work each specific deployment of Sidekiq does.
-Any other specialized deployments with processes dedicated to specific queues
-should have the concurrency tuned according to:
-
-- The CPU usage of each type of process.
-- The throughput achieved.
-
-Each thread requires a Redis connection, so adding threads may increase Redis
-latency and potentially cause client timeouts. See the [Sidekiq documentation about Redis](https://github.com/mperham/sidekiq/wiki/Using-Redis)
-for more details.
+<!-- end_remove -->
 
 ## Modify the check interval