fix(api): consider expiration return addresses for ledger updates

[DaughterOfMars]

This PR changes how the owning address is calculated for spent outputs. Rather than assume the address unlock condition for basic/NFT outputs, the spent timestamp is checked against the expiration unlock condition, if it exists. Therefore, in the case where the output was spent on or after the timestamp, we use the return address to index the output.

UPDATE: Rolled the changes for the balance endpoint in as well for simplicity. The endpoint now returns availableBalance instead of sigLockedBalance and the calculation has been adjusted to include outputs with timelock conditions that have become unlocked, as well as those with matching expiration return addresses that are expired.

Linked Issues

• Closes Include outputs relative to the return address unlock condition in the history endpoint  #1313
• Closes Update balance endpoint to stardust #1312

Notes to Reviewer

As a reviewer, please pay particular attention to the following areas when reviewing this PR and tick the above boxes after you have completed the steps.

API Changes

• Test the ledger updates by address endpoint.

INX Changes

• Run chronicle using an INX connection.

Database Changes

• Review database queries for correctness/conciseness.
• Review migration for correctness.

[Alex6323]

Maybe I am misunderstanding something but isn't it the case that when the output is still unspent, but the latest milestone timestamp > expiration timestamp, then the owning address should already be the return address?

with the current logic the owner of an unspent output would still be the address in the address_unlock_condition despite we're passed the expiration.

so maybe this should just be a MilestoneTimestamp as the argument and if the output is already spent, then it would be the spent_timestamp like currently, but when the output is still unspent then this should be the latest milestone timestamp, and the logic could remain the same.

[DaughterOfMars]

The problem is there's simply no good way for us to do this. We would have to update all unspent outputs every milestone, which is simply not performant. Spending proves definitively who the owner is, so we just update it then. Since this is only used in the explorer routes, this is fine. The only concern I have is with analytics, because we use it for active addresses, balance, and base token activity and those calculations may possibly be wrong now.

[DaughterOfMars]

https://chronicle-migr.stardust-mainnet.iotaledger.net/api/

This server can be used for testing the mainnet API before we commit to a migration.