Bugs and/or endpoint consistency between /drep_delegators and /pool_delegators endpoints

[MadOrkestra]

Writing up the results of a discussion I had on Telegram with @hodlonaut the other day. This all started with me checking gov.tools and stumbling across retired dReps which still show delegation. When I tried to verify on Koios, I found this is actually not possible right now, which led to discovering some inconsistencies (or maybe even bugs) over dRep endpoints compared to pool endpoints:

Is your feature request related to a problem? Please describe.
Once a dRep retires, accounts delegated to that dRep do no longer show on /drep_delegators - which they should, so we can track retired delegation over the entire ecosystem, consistent with the current pool endpoints.

Using drep1yf53zart87p9gdhumx6nzq0kstnttxqscth92euts58vy9c70swgq as example:

Govtools shows 145k delegation (can't verify)
https://gov.tools/drep_directory/drep1dyghg6elsf2rdlxek5csra5zu66esyxzae2k0zu9pmppw0yrjvr

/drep_info shows the dRep isn't registered anymore

curl -X POST "https://api.koios.rest/api/v1/drep_info" \ -H "accept: application/json"\ -H "content-type: application/json" \ -d '{"_drep_ids":["drep1yf53zart87p9gdhumx6nzq0kstnttxqscth92euts58vy9c70swgq"]}' \

/drep_delegators returns an empty array instead of accounts still delegated to this dRep:

curl -X GET "https://api.koios.rest/api/v1/drep_delegators?_drep_id=drep1yf53zart87p9gdhumx6nzq0kstnttxqscth92euts58vy9c70swgq" \ -H "accept: application/json"

If we do the same with a retired pool, we see these results:

/pool_info shows the pool_status is retired and retiring_epoch is 385:

curl -X POST "https://api.koios.rest/api/v1/pool_info" \ -H "accept: application/json"\ -H "content-type: application/json" \ -d '{"_pool_bech32_ids":["pool1c8k78ny3xvsfgenhf4yzvpzwgzxmz0t0um0h2xnn2q83vjdr5dj"]}'

/pool_delegators returns 3 accounts still delegated to the pool:

curl -X GET "https://api.koios.rest/api/v1/pool_delegators?_pool_bech32=pool1c8k78ny3xvsfgenhf4yzvpzwgzxmz0t0um0h2xnn2q83vjdr5dj" \ -H "accept: application/json"

(inconsistent with the data adastat and pool.pm displays, which both show 9 delegations left)

/pool_delegators_history for epoch 535 returns, oddly enough, an empty array

curl -X GET "https://api.koios.rest/api/v1/pool_delegators_history?_pool_bech32=pool1c8k78ny3xvsfgenhf4yzvpzwgzxmz0t0um0h2xnn2q83vjdr5dj&_epoch_no=535" \ -H "accept: application/json"

Describe the solution you'd like

I'd propose /drep_delegators returns the current delegators for the given dRep - in line with /pool_delegators (which also seems buggy, see example above) - even if the dRep is retired, because these delegators are still delegated to that dRep, even if their voting power is void and they won't be able to withdraw rewards. They have to re-delegate to change this, in line with how pool delegation works. This allows to track retired dRep delegation, reach out to retired dReps to inform their delegators again to re-delegate, etc.

Furthermore in line with the pool endpoints, there could be a new /drep_delegators_history endpoint to query delegators for a given dRep and a specific epoch.

For consistency /drep_info could use a field to output the epoch the dRep has retired (which means de-registered, inactive_since could also be a field, though not as important as there are no implications)

Additional context
Maybe I picked bad examples or missed something, but seems worth looking into further. Reading through the docs there are probably some distinctions to make: in the pool endpoints the wording is "live delegators" on /pool_delegators and "active delegators" in /pool_delegators_history ("active delegators" could be delegators to a live pool I guess, which then explains the empty array returned, because the pool is retired?) - with dReps it gets even more complicated because dReps can be registered but inactive - although this distinction isn't really important for the delegation question, because reward withdrawal is still possible for accounts delegated to inactive but registered dReps. Inactivity is merely a info for delegators that they should probably think about picking a less lazy dRep.

There is another inconsistency @hodlonaut found while testing: /account_info still shows retired dReps in delegated_drep - maybe we add this to this thread to be looked into and discussed.

[MadOrkestra]

Just checked the /pool_delegators return with another retired pool:

https://api.koios.rest/api/v1/pool_delegators?_pool_bech32=pool1u899yml96tf2cf4zkw4490mnhf832pk6fefnaluvt7487jmqzhg

This returns 8 delegators while pool.pm returns 13, consistent with the Adastat output