feat(python): add python implementation of InputAligner

[dvorak0]

Description

Fixes #282

Is this user-facing behavior change?

Did you use Generative AI?

Codex

Additional Information

Summary

• add a Python InputAligner implementation on top of the rolling branch
• export it from the Python package
• add Python parity tests matching the C++ test_input_aligner.cpp coverage

Details

This PR targets ros2/message_filters:rolling from UniflexAI/message_filters:rolling.
The Python implementation follows the C++ InputAligner semantics referenced from the upstream sa-input_aligner work.

Test coverage

The Python test file now covers 10 InputAligner cases, including the original C++ parity coverage plus Python-specific regression coverage for recent fixes:

• init
• dispatch_inputs_in_order
• dispatch_inputs_with_duplicate_timestamps
• reconnect_input_disconnects_old_callbacks
• ignores_inactive_inputs
• input_timeout
• drops_msgs
• dispatch_by_timer
• no_period_information
• get_queue_status

Validation

Validated on a Rolling environment with all 10 Python InputAligner tests passing.

[dvorak0]

@EsipovPA Here is the rolling version. Would you help again? Thanks.

[ahcorde]

1. Tie-break crash — input_aligner.py:108 puts (timestamp, msg) into a PriorityQueue. Equal timestamps fall through to comparing messages → TypeError. Add a sequence counter: (ts, seq,
   msg). The C++ version (a std::multiset keyed on timestamp) sidesteps this.
2. disconnectAll() doesn't disconnect — input_aligner.py:81. It clears only the local list; upstream SimpleFilter callbacks stay live. Re-calling connectInput with fewer inputs →
   IndexError on the next upstream message. SimpleFilter (init.py:54) has no unregister API — that needs to be added.
3. Race in connectInput — input_aligner.py:72-79 replaces event_queues/signals without the lock while add can still fire.

[dvorak0]

@ahcorde I've fixed the issues, and added two more tests coordinating to issue 1 & 2.

[EsipovPA]

Suggested change

	def registerCallback(self, cb, *args):
	def registerCallback(
	self,
	callback: tp.Callable[
	[
	expected,
	argument,
	types
	],
	expected_return_type
	],
	*args
	) -> int:

As the typing is already imported, why not use it to the full extend? Is the return type an int?

[EsipovPA]

Suggested change

	self.callbacks = {}
	self.callbacks: dict[key_type, value_type] = {}

It seems to me that the value_type is something like tp.Callable[[...], ...]

[EsipovPA]

IMHO, this type hint is not really informative. It is the same as just

Suggested change

	callback: tp.Callable[..., tp.Any],
	callback: tp.Callable,

But it does not privide info about the callback signature. Myabe extend this type hint?

[dvorak0]

I agreed the info is too loose. How can I do better when they are callbacks, which means I don't know about it much. What do you recommend to do.

[EsipovPA]

I'll need to take a look into the source code for that. I'll be back with an answer.