Count threads all that run in multithreaded env

This adds the threads we know are running next to the worker threads
for Puma and Sidekiq. Adding them here makes sure our connection pool
for the database is large enough.

In puma, the main thread also connects to the database, so we need to
count that.

In Sidekiq, the main thread and the poller for Sidekiq cron could also
connect to the database.

changelogs/unreleased/bvl-correct-thread-count.yml

+---
+title: Fix sidekiq jobs not always getting a database connection when running with low concurrency
+merge_request: 25261
+author:
+type: fixed

lib/gitlab/runtime.rb

@@ -78,12 +78,16 @@ module Gitlab
       end
 
       def max_threads
+        main_thread = 1
+
         if puma?
-          Puma.cli_config.options[:max_threads]
+          Puma.cli_config.options[:max_threads] + main_thread
         elsif sidekiq?
-          Sidekiq.options[:concurrency]
+          # An extra thread for the poller in Sidekiq Cron:
+          # https://github.com/ondrejbartas/sidekiq-cron#under-the-hood
+          Sidekiq.options[:concurrency] + main_thread + 1
         else
-          1
+          main_thread
         end
       end
     end

spec/lib/gitlab/runtime_spec.rb

@@ -50,7 +50,7 @@ describe Gitlab::Runtime do
       allow(puma_type).to receive_message_chain(:cli_config, :options).and_return(max_threads: 2)
     end
 
-    it_behaves_like "valid runtime", :puma, 2
+    it_behaves_like "valid runtime", :puma, 3
   end
 
   context "unicorn" do
@@ -71,7 +71,7 @@ describe Gitlab::Runtime do
       allow(sidekiq_type).to receive(:options).and_return(concurrency: 2)
     end
 
-    it_behaves_like "valid runtime", :sidekiq, 2
+    it_behaves_like "valid runtime", :sidekiq, 4
   end
 
   context "console" do