Notify policy about broken input channels

The InputDispatcherPolicyInterface contains a callback for
'notifyInputChannelBroken'. Looking at the implementation of the policy
for this callback, inside InputManagerCallback.java, the intent of this
callback is to call windowState.removeIfPossible(). In other words, try
to remove the window when the input channel is broken.

In the input code, this could be triggered in 3 different ways:
1) pipe is full (WOULD_BLOCK), but the wait queue is empty
2) can't write to socket, but the error is other than 'WOULD_BLOCK'
3) 'removeInputChannelLocked' is called

The first two cases don't really happen in practice. The last case can
happen when the app closes the socket, but the window still remains on
the screen (maybe temporarily).

It turns out, before this patch, the policy was never getting notified
for the case 3) either. That means, this API has not been called in a
very long time (> 7 years from brief look through the code history).

It was never getting called because the policy callback is skipped if
the input connection is marked as 'zombie'. However, in
'removeInputChannelLocked', the connection is marked as 'zombie' as soon
as the notifyInputChannelBroken command is queued. So in practice, the
connection is already zombie before the policy notification can happen.

In this CL, we remove the check for the connection being zombie. We will
always notify, since once an fd is closed, there's no way to recover
from that.

If this CL causes breakages because this code path is now going to be
triggered, we should either fix the WM implementation of this callback,
or we should just remove this policy callback altogether.

Bug: 206861133
Test: atest inputflinger_tests
Change-Id: Iaaf5e9c3a2681d7afa444913bd6f2686c413e7df