queue_processors: Disable timeouts with PushNotificationsWorker.
queue_processors: Disable timeouts with PushNotificationsWorker.

Since 385328524174, PushNotificationsWorker uses the aioapns library
to send Apple push notifications.  This introduces an asyncio event
loop into this worker process, which, if unlucky, can respond poorly
when a SIGALRM is introduced to it:

```
[asyncio] Task exception was never retrieved
future: <Task finished coro=<send_apple_push_notification.<locals>.attempt_send() done, defined at /path/to/zerver/lib/push_notifications.py:166> exception=WorkerTimeoutException(30, 1)>
Traceback (most recent call last):
  File "/path/to/zerver/lib/push_notifications.py", line 169, in attempt_send
    result = await apns_context.apns.send_notification(request)
  File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/client.py", line 57, in send_notification
    response = await self.pool.send_notification(request)
  File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/connection.py", line 407, in send_notification
    response = await connection.send_notification(request)
  File "/path/to/zulip-py3-venv/lib/python3.6/site-packages/aioapns/connection.py", line 189, in send_notification
    data = json.dumps(request.message, ensure_ascii=False).encode()
  File "/usr/lib/python3.6/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/lib/python3.6/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.6/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/path/to/zerver/worker/queue_processors.py", line 353, in timer_expired
    raise WorkerTimeoutException(limit, len(events))
zerver.worker.queue_processors.WorkerTimeoutException: Timed out after 30 seconds processing 1 events
```

...which subsequently leads to the worker failing to make any progress
on the queue.

Remove the timeout on the worker.  This may result in failing to make
forward progress if Apple/Google take overly long handling requests,
but is likely preferable to failing to make forward progress if _one_
request takes too long and gets unlucky with when the signal comes
through.

kou/zulip,kou/zulip,rht/zulip,kou/zulip,zulip/zulip,kou/zulip,zulip/zulip,zulip/zulip,eeshangarg/zulip,rht/zulip,eeshangarg/zulip,kou/zulip,rht/zulip,rht/zulip,andersk/zulip,andersk/zulip,andersk/zulip,eeshangarg/zulip,eeshangarg/zulip,zulip/zulip,rht/zulip,andersk/zulip,andersk/zulip,kou/zulip,eeshangarg/zulip,rht/zulip,kou/zulip,andersk/zulip,eeshangarg/zulip,eeshangarg/zulip,rht/zulip,zulip/zulip,zulip/zulip,andersk/zulip,zulip/zulip