Fix RequestsInstrumentor for custom transport adapters

[mariojonke]

The RequestsInstrumentor contained some dead code from an early metrics implementation that in certain situations failed with an AttributeError. The AttributeError happened when trying to determine the HTTP flavor from the raw.version attribute on the returned Response object.
By default, the raw attribute is an urllib3 response that has the version attribute. However, requests allows mounting custom transport adapters for certain URLs.
A custom adapter can return a Response where the raw object isn't an urllib3 response and the version attribute might not be present. Thus, the RequestsInstrumentor could run into an AttributeError.

This change removes the dead metrics code.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Additional unit test to verify that the RequestsInstrumentor works with custom transport adapters.

Does This PR Require a Core Repo Change?

• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added

[codeboten]

Change looks good, I just have one question before approving.

[codeboten]

These changes don't seem directly related to the description of this change, were these attributes superfluous?

[srikanthccv]

I think this is the dead code @mariojonke is talking about in the PR description.

[mariojonke]

Yes, the labels are a leftover from the old metrics implementation. Since all the metrics related code got removed, the labels are unused.

[srikanthccv]

Do client semantic conventions allow http.falvor? I think we could do something like hasattr and add the span attribute instead of entirely removing it? WDYT?

[mariojonke]

Semantic conventiosn for http.flavor exist in the spec for server and client spans.
However, parsing the flavor from the response might be unreliable since

1. a custom response might also have a version attribute
2. even if it is a urllib3 HTTPResposnse the version attribute is provided only from yet another response object. Usually it is a http.client.HTTPResponse but i'm not sure if this is always the case.
   So the format of the version attribute might actually be different from what is expected.

Also, I think the removed code for parsing the version appears to be incorrect. In the HTTPResponse docs the version is defined as 10 for HTTP/1.0 and 11 for HTTP/1.1. However, for 10 the http.flavor attribute would be parsed to 1.1 due to how the version string is sliced.

[codeboten]

@lonewolf3739 please approve if your comments have been addressed, thanks!