feat(asgi,fastapi,starlette)!: provide both send and receive hooks with scope and message

[eigenein]

Description

Currently, a «receive» hook is only provided with scope, but not message. On contrary, a «send» hook is only provided with message, but not scope.

This change unifies the both hooks and provides them with additional request info.

This is a breaking change:

• The hooks will now be provided with one more positional argument
• client_request_hook will be called after receive() instead of before receive()

Resolves #2560.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Existing unit tests have been updated.

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: eigenein / name: Pavel Perestoronin (8010527)

[eigenein]

Fixed the linter errors, let's try it again

[eigenein]

Ready for review

[tammy-baylis-swi]

Thank you for submitting this! A couple of asks:

client_request_hook will be called after receive() instead of before receive()

(1) How has this been tested? Does the hook still work the same way to e.g. set span name or attributes?

(2) Please could you also create and link a github Issue describing the feature, like how this PR links this issue, especially because this would be a breaking change.

[eigenein]

Sure, thanks for looking into it!

1. There are existing tests for hooks, that verify the hooks keep working the same way (they test exactly setting span name & attributes, and would've gone red should I break anything):

   • ASGI
   • FastAPI
   • Starlette

   Of course, they went red because I added the new parameters, so I just updated the test hooks in there.

   The call order change here basically ensures that the hook could access the ASGI event. No functional changes, otherwise. I don't think the call order was part of the public interface, but pointed it out – just in case.

2. Would you like me to just copy-paste the description, or would you need some additional info in there? This pull request is pretty self-contained, there was no bug or feature request in the first place.

[tammy-baylis-swi]

The call order change here basically ensures that the hook could access the ASGI event. No functional changes, otherwise. I don't think the call order was part of the public interface, but pointed it out – just in case.

Great thanks!

2. Would you like me to just copy-paste the description, or would you need some additional info in there? This pull request is pretty self-contained, there was no bug or feature request in the first place.

Yes please a copy-paste works 🙂

[tammy-baylis-swi]

Also Lgtm, nice to see those types in shared ASGI module. We'll get eyes from the maintainers as well.

[eigenein]

Done!

[eigenein]

Rebased and corrected the changelog