Currently, stream.Debounce can emit a spurious event when the source stream
terminates. Indeed, at that point, the items channel gets closed, and the
completion error is published to a separate error channel. Depending on the
(undeterministic) select unblocking order, we may first observe the items
channel closure, hence emitting the default value of the object, and only
afterwards propagate the termination error.

Let's fix this issue by checking whether the items channel unblocked
because it had just been closed, and do not emit any item in that case.
Additionally, let's also slightly adapt the corresponding test to catch
this issue: we never discovered it because another event had just been
emitted, and the spurious one was just queued. Adding an extra delay,
instead, causes the test (without this fix) to almost always hang,
because of the spurious event not being received by anyone.

Additionally, let's also prevent entering into a busy loop when the
items channel gets closed, until we receive on the errors channel,
by immediately setting it to nil afterwards. Thanks to David Bimmler
for pointing out this issue.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>