v2.2.x CHORE - Ignore select style RUFF warnings in config

[reactive-firewall]

RUFF needs a Config

Namely:

• it should be configured to aline with CEP-7 and CEP-8 and CEP-9 conventions
  • ignore:
    • PT009 - project supports unittest style asserts
    • G004 - in multicast/exceptions.py and all of test/*.py as the wrong abstraction
    • UP009 - not specifying utf-8 deviates from project convention
    • UP008 - review this for wrong abstraction
    • S603 - review for dumb-check

[reactive-firewall]

Regarding explicit super:

*Warning* There are a few reasons why this repository's code uses `super(Class, self)` to achieve more compatibility rather than using just `super()` implicit.

### Reasons
- When using duck typing in the child classes but different non-related parent classes there is a cleaner stacktrace when the parent class is given explicitly to `super`.
- Using explicit `super` calls helps find when the parent class was changed i.e., when refactoring parent class names, the explicit parent in the `super` calls will also need to be changed.
- Because, of above it also helps debug when the same name of a child class is `ClassNameMixin` so it is not ambiguous when `ClassNameMixin` inherits from `ClassNameBase` but `AnotherClassNameMixin` inherits from the same `ClassNameBase` so the parent is now explicit in the `super` of each mixin call.
- Because, this helps support python in general like before version 3 which some distro's still use, implicitly.

### Refactoring tip:
* Follow the "Zen of Python", where "explicit is better than implicit", is being considered in the case of following the explicit parent when defining complex class hierarchies.
* Consider this repo's use of `super(ClassName, self)` is actually a choice made in support of explicit code style like that in [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161).

Body preview: 

https://github.com/reactive-firewall/multicast/issues/360

Originally posted by @coderabbitai[bot] in #351 (comment)

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@reactive-firewall Thank you for providing this detailed explanation about your preference for explicit super(Class, self) calls. I've noted your rationale including the benefits for stacktraces, refactoring, reducing ambiguity in complex inheritance hierarchies, and maintaining compatibility with older Python versions. I'll continue to respect this coding style choice in my future reviews, in alignment with your project's CEP-8 inspired guidelines and the "explicit is better than implicit" principle from the Zen of Python.

---

🧠 Learnings used

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#330
File: tests/test_install_requires.py:60-60
Timestamp: 2025-03-17T05:14:38.495Z
Learning: In the multicast project, reactive-firewall prefers the explicit super call style `super(ClassName, self).method()` over the simplified `super().method()` form.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#330
File: tests/test_install_requires.py:49-50
Timestamp: 2025-03-17T05:53:41.672Z
Learning: In the multicast project, reactive-firewall prefers to keep the more explicit form of super() calls (e.g., super(ClassName, self).method()) rather than the simplified super().method() form that's common in modern Python 3 code.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#351
File: multicast/hear.py:535-542
Timestamp: 2025-04-14T01:46:10.581Z
Learning: Reactive-firewall prefers using the explicit form of super() calls (e.g., super(ClassName, self)) rather than the shorter Python 3 form super().

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#351
File: tests/test_recv.py:56-56
Timestamp: 2025-04-14T01:56:26.897Z
Learning: The multicast project deliberately uses explicit `super(ClassName, self)` calls instead of `super()` to maintain compatibility with older Python versions, provide cleaner stacktraces when using duck typing, make refactoring easier, and reduce ambiguity in complex inheritance hierarchies. This is a specific code style choice documented in GHI #360 and aligned with CEP-8, following the "explicit is better than implicit" principle from the Zen of Python.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#115
File: multicast/hear.py:180-180
Timestamp: 2024-10-08T21:59:30.537Z
Learning: Reactive-firewall prefers to re-use already loaded modules to keep memory overhead low when possible.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#115
File: multicast/hear.py:180-180
Timestamp: 2024-09-19T03:43:24.037Z
Learning: Reactive-firewall prefers to re-use already loaded modules to keep memory overhead low when possible.

[reactive-firewall]

example of an MIT-licensed ruff:

config:
https://github.com/jaraco/skeleton/blob/5a6c1532c206871bc2913349d97dda06e01b9963/ruff.toml#L1-L51