Resolve "Track the number of new Redis connections per transaction"
## What does this MR do?
Add a new metric counter, `new_redis_connections`, that contains the number of calls to `Redis::Client#connect` in the current transaction.
## Are there points in the code the reviewer needs to double check?
Not sure. I tested this in kind of a brute-force way:
1. Add a debugger in the monkey-patched `connect` method.
2. With metrics enabled, start the app and load a page.
3. The first Redis connection is created by `Rack::Attack` and isn't in a transaction, but still works fine.
4. The second Redis connection is within a transaction (the page load), and increments the counter.
5. If I reload the page, neither debugger is hit.
6. If I use a Redis client and do `CLIENT KILL` on my two existing clients, then reload the page, I get 3 and 4 again.
7. If I disable metrics collection, the debugger never gets hit.
## Why was this MR needed?
We may have a Redis connection leak somewhere, so adding metrics will let us track this.
## What are the relevant issue numbers?
Closes#18451.
## Screenshots (if relevant)
Hahaha nope, not relevant.
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- [ ] Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @yorickpeterse
See merge request !4649
By default instrumentation will instrument public,
protected and private methods, because usually
heavy work is done on private method or at least
that’s what facts is showing
Improve Gitlab::Auth method names
Auth.find was a very generic name for a very specific method.
Auth.find_in_gitlab_or_ldap was inaccurate in GitLab EE where it also
looks in Kerberos.
See merge request !4589
Upgrade devise, devise-two-factor, and attr_encrypted
Devise 4 includes support for Rails 5, working towards #14286. devise-async doesn't support Devise 4.0 and in 4.1 the bug that was blocking using Devise's built-in ActiveJob integration was fixed. So devise-async is removed. devise-two-factor 3.0.0 is required for Devise 4 support.
attr_encrypted and encryptor are optional but recommended upgrades for devise-two-factor 3.0.0. The mode and algorithm will need to be changed in order to update to attr_encrypted 4.x in the future.
See merge request !4216
Enable Style/NegatedIf Rubocop cop
Favor `unless` over `if` for negative conditions (or control flow ||).
```ruby
# bad
do_something if !some_condition
# bad
do_something if not some_condition
# good
do_something unless some_condition
# good
some_condition || do_something
```
See #17478
See merge request !4355
fix#15127 ActiveJob::DeserializationError thrown
`send_devise_notification` pre-maturely enqueued the task when the user instance
has not yet been committed into the database, causing a record-not-found in the
other sidekiq process.
`devise-async` has already been taking care of asynchronous mail sending, we just
need to run it inside queue `mailers` instead of `mailer` to enable it.
The implementation of `devise-async` enqueues the task in `after_commit` hook
which is the right way to do it.
See merge request !3647
Enable the Rubocop DeprecatedClassMethods cop
This reports uses of `File.exists?` and `Dir.exists?`, which were both
deprecated in Ruby and will eventually be removed in favor of `.exist?`.
Also fixes all existing uses of the deprecated methods.
See merge request !4087