This introduces the same pattern of instrumentation [we use for
Redis](https://gitlab.com/gitlab-org/gitlab/-/blob/b16db2726d7b429d740ef3642dda13b528fc4fda/lib/gitlab/instrumentation/redis.rb).
This MR also adds the instrumentation details to sidekiq logs like we do
with Redis.

This instruments at the lowest level by instrumenting the
elasticsearch-transport gem which is used by the elasticsearch-rails gem
and elasticsearch-api gem which are the higher level abstractions used
by GitLab. This has been tested to log requests coming from both places.

Other options considered for this solution involved following a similar
pattern to
https://github.com/elastic/elasticsearch-rails/blob/1c3226d8186af6e8446fa5091f5b27760c29f896/elasticsearch-rails/lib/elasticsearch/rails/instrumentation/log_subscriber.rb
which would extend the log subscriber pattern to be more than just
searches in the context of the elasticsearch-rails gem but this seemed
more convoluted than the approach I took since it requires monkey
patching to publish a message then a separate class to subscribe and
store those messages and so the pattern didn't seem to be beneficial
unless you plan to have multiple subscribers.

Additionally I considered using Faraday middleware to track this since
the Elasticsearch gem uses Faraday by default but again I opted not to
do that since it seemed trickier to manipulate the client config
following
https://github.com/elastic/elasticsearch-ruby/tree/master/elasticsearch-transport#transport-implementations
and implement the required middleware etc. than just prepending the
method following the same pattern as Redis.