Correct threadcount in multithreaded environments

What does this MR do?

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 als connect to the database.

This is part of the changes for gitlab-com/gl-infra/scalability#152 (closed) as seen in https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/9198 we've upped the numbers of the queues with the lowest concurrency. But we're still seeing this for other queues:

https://log.gprd.gitlab.net/goto/b7b6c6e6229aae2ddc9f9403ee825f7e

This is less visible there because the concurrency is higher and therefore there's chance a thread does not have a connection available.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done