Use a no-op order manager for in-order queues

[ndgrigorian]

As pointed out in #2293, the SequentialOrderManager construct may not bring any benefit with in-order queues, and, with an in-order queue, an extension/function implementation has to insert events into the SequentialOrderManager if using library calls which also use SequentialOrderManager unnecessarily.

To remedy this, this PR proposes adding a _NoOpOrderManager implementation class that SequentialOrderManager can use when passed an in-order queue.

The returned object isn't cached, as it's mostly a no-op. Notably, the _NoOpOrderManager stores the in-order queue that it was given, so that wait() can call q.wait() so that the method is still meaningful.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?
• If this PR is a work in progress, are you opening the PR as a draft?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpctl/pulls/2299/index.html

[coveralls]

coverage: 75.595% (+0.1%) from 75.476% — no-op-order-manager-for-in-order-queues into master

[ndgrigorian]

@antonwolfy @vlad-perevezentsev
this is ready for review, since this impacts order manager, it will impact all of tensor and dpnp. On my tests so far, I have seen no issues, but I will keep trying.

Please experiment with it as well

[antonwolfy]

Would it make sense to implement a protocol instead of union to have a pure type-checking construct?

from typing import Protocol

class OrderManagerProtocol(Protocol):
    """Protocol defining order manager interface"""
    
    def add_event_pair(self, host_task_ev, comp_ev) -> None: ...
    
    @property
    def num_host_task_events(self) -> int: ...
    
    # ... etc

def __getitem__(self, q: SyclQueue) -> OrderManagerProtocol:
    # type checkers understand this is an interface

[ndgrigorian]

we could, though also, we could just use | instead of the Union since we restrict to >=3.10 anyway.

I'll try the protocol approach and see if it saves some redundancy

[antonwolfy]

Is it expected there will be no wait() called for that queue on clear method below?

[antonwolfy]

I wonder about finalization of tasks from in-order queue at exit

[ndgrigorian]

Is it expected there will be no wait() called for that queue on clear method below?

I think it makes sense in the sense that, no events were present in it to begin with. The original SequentialOrderManager calls the wait on its own events, but this order manager, owns no events. But I see your point about the finalization though, it's fair: unlike the normal order manager, this one wouldn't clear.

We will need to track some queues, I think.