Fix CustomMessageListener class, and update example and documentation

[samuelspagl]

This is an implementation of the changes mentioned in #2195 which therefore can be closed.

Content of the PR

In previous commits there was the CustomMessageListener class implemented, to add type hinting to the message listeners.
This PR is fixing the bug of not being able to utilise this typehinting class. It makes sure to enable users to use the @CustomMessageListener decorator for their listener functions, while still being backwards compatible.

Changes made

In runners.py

class CustomMessageListener(Protocol):
    @abstractmethod
    def __call__(self, environment: "Environment", msg: Message) -> None:

to

class CustomMessageListener:
    def __init__(self, f):
        self.f = f  # Store the function

    def __call__(self, environment: "Environment", msg: Message) -> None:
        self.f(environment=environment, msg=msg)

Additional Changes:

Updated the custom_messages.py example and the running-distributed.rst documentation file.

[samuelspagl]

ping @nathan-beam, @cyberw

[cyberw]

Looking at the updated example I'm not sure about this. This is different from other Locust event handlers work, and I'm not sure if the added complexity (importing a class, tagging the method) is worth it. But lets have Nathan weigh in.

[samuelspagl]

Okay :) then let's wait.

Just to be on the same page: it is fully backwards compatible. So you can also just use it without the decorator. It's just for the type consistency.

So the other side would be completely deleting the typehint?

For me it was very confusing to have this not working as expected type hint :)

[cyberw]

Right, we shouldnt have incorrect type hints either, so thats not an option :)

[samuelspagl]

So any news about this? :) Just wanna check.

[cyberw]

I guess @nathan-beam is asleep. I dont like having to introduce a decorator to the examples. There should be some more user friendly solution. But I’m afk, and probably wont really have the energy once I get back :)

[samuelspagl]

Okay, so rn I don't have another solution for this. I honestly think that the decorator is kinda the cleanest method, as it also is not breaking any existing code.

Then I would propose to remove the CustomMessageListener class completely. That way it will be type consistent again.
I can prepare a PR, if you want that. :)

[cyberw]

I think that might be a good idea. That class never really made sense to me :) If you make a PR I’ll be sure to review it.