fix: ensure notify payload is never too big

[rissson]

Closes #84

• adds a failing test case (the one named almost_too_big)
• adds another test case for payloads too big, I don't think one was ever added
• adds a migration to fix the issue
• fixes old migrations reverse sql. You can't drop the function while the trigger still exists as it depends on it

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 79.66%. Comparing base (300a32b) to head (2b0c31f). :warning: Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #86   +/-   ##
=======================================
  Coverage   79.66%   79.66%           
=======================================
  Files           4        4           
  Lines         359      359           
  Branches       30       30           
=======================================
  Hits          286      286           
  Misses         63       63           
  Partials       10       10           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rissson]

Unfortunately we stopped using this library and instead re-wrote an implementation more suitable for our needs. Our main problem was that the postgres pool wasn't scoped to a specific loop, so it might end up be used by multiple loops which causes exceptions. We've re-written this to do it more like https://github.com/django/channels_redis/blob/main/channels_redis/pubsub.py which creates one layer per loop.

I'll leave this PR up and my fork as well, so if you want to pull those changes in, feel free to, but I won't be committing more time to this change.

Thank you for your work and understanding!

[danidee10]

I can see how this would be a problem.

There's actually a test in the repo that checks if receiving from two event loops on the same channel layer instance works and it passes. I'd have to review the test to understand why it's not failing.

Thanks for the contribution! I will make some small changes and merge it