While there are no "documented" limits on how many and how fast you can send your push requests, obviously things are not unlimited.
While there are not set limits enforced, by consequence of how things work, and for the protection of the APNs service, your push requests can get throttled, your connections dropped, and in the end your IP address could get blocked.
These are issues you will run into during runtime, and App Review will not know that in advance, unless there are complaints, then they may get involved.
If you are asking for recommendations, then it will be to not try to work around limitations.
While you can certainly try to overcome the 30 second alarm duration limit, we can't say whether your push request pattern will trigger any protections beforehand. What I would suggest is, if you do this, monitor the responses from APNs closely, and if you see errors, correct them before continuing, and if you start seeing your connections dropped, or no longer be able to make connections, to back off to let the error states reset. If APNs starts dropping your connections or blocking your IP addresses, there will be no way to continue sending push requests until you resolve the issues that caused the state.
And on the practical side, you need to understand how quick succession push requests are stacked. APNs holds a queue of 1 undelivered push request. If another push request arrives before it is delivered, the first one is overwritten by the second one, and so on. So, if the device is offline, or is in a spotty/slow connection so the notifications cannot be delivered immediately, then the subsequent push requests will overwrite the previous ones, and when the device becomes available again, they will only get the last single notification.
