remove access to patching elasticsearch client directly as it is not supported anymore by elasticsearch

[ekump]

2.0 Upgrade Guide notes

In 1.x, both the ElasticSearch "client" and ElasticSearch "transport" can be configured:

Datadog.configure_onto(client, **options)
Datadog.configure_onto(client.transport, **options)

But the ElasticSearch "client" is not available across all versions of the ElasticSearch gem, which makes configuration unreliable, while the "transport" is.

In 2.0, only ElasticSearch "transport" can be configured:

Datadog.configure_onto(client.transport, **options)

Could use a hand in crafting a proper upgrade note for this one

What does this PR do?
Removes the ability to instrument a client object of Elasticsearch as the client object is not available as of Elasticsearch 8.0. Instrumenting the transport object is available in all versions.

Motivation:
Makes ES integration consistent between versions

Additional Notes:

How to test the change?

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

[ekump]

@marcotc @TonyCTHsu When I added back this test to allow custom config on the transport object it initially failed. Turns out that prior to ES 8.0 client.transport refers to the client instance. client.transport.transport refers to the transport instance. With ES > 8.0 client.transport refers to the transport instance. So when I changed the patch of perform_request to not check Datadog.configuration_for(self, :service_name) and only do Datadog.configuration_for(transport, :service_name) it was getting back nil on ES 7.0 since there is a discrepancy between what we set with configure_onto and what we get with configuration_for.

As I see it we have 3 options:

1. Keep my changes as they are, and update the docs to explain that if you are on ES < 8.0 you need to configure_onto client.transport.transport. This makes our code simpler, but our docs slightly more complicated.
2. Keep my code changes, update the this test to skip ES < 8.0, and update our documentation to say we don't support custom configuration for transport below ES 8.0
3. Change the code so that if ES < 8 we support configuration on the client object, but not support it for 8.0+ and remove the deprecation warning.

I think option 1 is the best balance of user-friendliness and code simplicity.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (277b90f) 98.10% compared to head (3ac27d8) 98.08%.
Report is 54 commits behind head on 2.0.

Additional details and impacted files

@@            Coverage Diff             @@
##              2.0    #3399      +/-   ##
==========================================
- Coverage   98.10%   98.08%   -0.02%     
==========================================
  Files        1252     1252              
  Lines       72342    72339       -3     
  Branches     3387     3386       -1     
==========================================
- Hits        70974    70957      -17     
- Misses       1368     1382      +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ekump]

@TonyCTHsu Is this the pattern we want to follow in situations where the instance we're trying to instrument may be different between versions of an integration? I didn't see any other direct examples of this (We do patch pinning in mongodb for different reasons).

I have two questions/concerns:

1. Is the complexity / indirection we're adding to our code worth the tradeoff of simpler configuration?
2. Are we potentially confusing users by masking ES implementation details like this? client.transport refers to a different object depending on ES version and we're providing a way to configure on an instance of that object. I could see the merit of an argument that we shouldn't be changing that object behind the scenes.

I lean slightly towards not doing this, but I don't have a strong opinion. At the end of the day either the library or the user has to set a different instance depending on ES version.

CC: @delner @marcotc in case you have any thoughts on a general strategy for these types of situations. We should probably agree on a pattern so we are consistent the next time it occurs. Some context.

[ekump]

Closing the loop on this: Spoke to @marcotc and @TonyCTHsu and we all agreed with this pattern.