[UR][CTS] Replace urEnqueueEventsWait with dummy event in waitlist tests

[kswiecicki]

InvalidNullPtrEventWaitList tests used urEnqueueEventsWait as the first
operation on a queue to create a valid event for validation testing.
This triggers a hang in the L0 driver when multiple test shards
concurrently call zeCommandListAppendSignalEvent +
zeCommandListHostSynchronize on immediate command lists.

Replace with urEventCreateWithNativeHandle(0, ...) which creates a
dummy event without enqueuing any work, avoiding the L0 driver
concurrency issue entirely. The validation layer rejects invalid
waitlist arguments before reaching the adapter, so the dummy event
is sufficient for these tests.

[pbalcer]

This isn't equivalent to urEnqueueEventsWait. It will not wait for the preceding operations on the queue.

[kswiecicki]

It's the EnqueueBarrier function that is being tested, urEnqueueEventsWait was used just to obtain an event.

[pbalcer]

What is the actual issue in L0? Hang if zeCommandListAppendSignalEvent is immediately followed by zeCommandListHostSynchronize, when the command list is otherwise empty?

[kswiecicki]

What is the actual issue in L0? Hang if zeCommandListAppendSignalEvent is immediately followed by zeCommandListHostSynchronize, when the command list is otherwise empty?

Yes, the issue seems to occur when multiple processes call zeCommandListAppendSignalEvent + zeCommandListHostSynchronize on an empty immediate command list. It occurs regardless of event creation API used (zexCounterBasedEventCreat2 vs zeEventCreate + counter based property descriptor).