There is currently no case where polling a finalized item more than once is desirable.
This patch limits the polling for all finalized types, not just invalidated blocks. Invalidated
items of types other than blocks are not tracked due to transient factors (for example,
immature proofs may be invalidated but once mature they can be finalized). And future changes
to voting policies on non-block items makes this challenging to navigate. However we can be sure
that once a block is invalidated we don't care about descendants. We will not reorg to an
invalidated chain.

Rationale on the filter size:
Using BTC as a proxy, block propagation for 90 percentile has been under 12 seconds for the last few years: https://www.dsn.kastel.kit.edu/bitcoin/#propagation
Assuming each cycle of polling finalizes a set of items in ~3 seconds, we assume 15 seconds is a window of time we can be reasonably sure a <1MB block will finalize across the network.
It is desirable to not allow repolling of recently finalized blocks (see D13207), so it is essential that this 15 second window be covered by the filter and not allow
the block to roll out of it prematurely. 20 polling cycles (128+ rounds to reach finalization for each "cycle") should take ~60 seconds so this should be sufficient even if you tweak assumptions, such as:

• eCash can have larger blocks and therefore slower block propagation time.
• The eCash network is smaller than BTC and may have less optimal paths that impact 90 percentile propagation time.

Depends on D13207