pool_updates: fields related to retirement aren't snapshots from the update but show current status

[robinboening]

Describe the bug
Requesting pool updates returns a a list of snapshots of the values when the updates were issued. Though, this is only true for most columns. If you request updates for a retired pool you'll notice retiring_epoch is set in every single update item, even for the initial registration of the pool, the same applies to pool_status which is filled with retired in every item.

You could argue this is intended, but I'd say it is not only very confusing as all the other columns are snapshots while these two always represent current state. It also prohibits me to detect what update is responsible for a deregistration. And, if I want to see the current status of a pool I'd request the pool_info endpoint.

To Reproduce
Steps to reproduce the behavior:

1. request pool_updates with pool1y2gynck9pd4en5rzm0rueqd2qm7sw89aqmkcntd899vv237qj38
2. See the retiring_epoch and pool_status fields filled in all items.

Expected behavior

I expect the response to

• include all updates (including deregistrations, see Add data-test.sh #26)
• only fill retiring_epoch in update items with transactions carrying a deregistration certificate
• set pool_status to retired only in update items AFTER the retiring_epoch is reached AND the update doesn't reregister
• set pool_status to retiring only in update items AFTER a deregistration had been issued and BEFORE the retiring_epoch is reached

Screenshots
response for the retired pool mentioned above. It is missing 2 deregistration updates (#26) and it shows values for pool_status/retiring_epoch aren't snapshots of when the update was issued but current state.

[rdlrt]

Thanks for raising - Same cause as #240, will be fixed together (pool_status in cache is updated based on current state, ending in messing up logic for filtering), will be tracked via #240