Change http.request.body.size and http.response.body.size attributes from recommended to opt-in

[trask]

Fixes #456

Changes

There are a few concerns with http.request.body.size and http.response.body.size:

• They are not useful enough to justify their current "Recommended" requirement level
• They are defined in terms of the Content-Length header which can already be captured as http.request.header.content-length and http.response.header.content-length
• They should potentially be defined in terms of actual bytes read, since Content-Length is not always available, and actual bytes read could be different anyways if the request/response was cancelled.

This PR does two things:

• Removes them from HTTP semconv (effectively making them opt-in)
• Explicitly marks them as experimental, along with a comment not to mark them stable when we mark the other HTTP attributes as stable next week

I will send a separate PR to propose changes to the definition of these attributes based on the other concerns above.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions.

[AlexanderWert]

@trask I think you need to regenrate the tables

[pyohannes]

I guess we should then consider doing the same for messaging (messaging.message.body.size and messaging.message.envelope.size) and RPC (message.compressed_size and message.uncompressed_size)?

[trask]

I guess we should then consider doing the same for messaging (messaging.message.body.size and messaging.message.envelope.size) and RPC (message.compressed_size and message.uncompressed_size)?

I opened #474 to discuss/track