Use pending_rewards for claimed info in related endpoints

[Imod7]

Description
Track this issue paritytech/polkadot-sdk#4313 to see when pending_rewards are in production so it can be used for the claimed information in the related endpoints (staking-info, staking-payouts).

More info

• pending_rewards will return true as long as there is a page to claim
• example here [Staking] Runtime api if era rewards are pending to be claimed polkadot-sdk#4301

Related to #1445

[IkerAlus]

Will this "simply" add a new field pending to the endpoint response? If that is the case, is this pending rewards information not available (doing a bit of local computation) in current and previous versions of the staking pallet? This way we would have a stable output format.

[Imod7]

Will this "simply" add a new field pending to the endpoint response? If that is the case, is this pending rewards information not available (doing a bit of local computation) in current and previous versions of the staking pallet? This way we would have a stable output format.

No, my intention was not to modify the endpoints' responses as soon as pending_rewards goes live, only to check if it can be used to simplify the internal calculations in our endpoints. The reason I added this issue was more of a tracker issue to re iterate through the logic as soon as it is available. It could potentially make the code simpler and more efficient.

Based on this comment for example, the response under claimed will now be something like this:

"claimedRewards": [
      {
        "era": "1322",
        "status": "claimed"
      },
      {
        "era": "1323",
        "status": "unclaimed"
      },
      {
        "era": "1324",
        "status": "partially claimed"
      },

which is calculated by currently comparing the results from 3 calls and quite a few if else statements. So if pending_rewards can be used to reduce this, maybe it is worth re iterating. Wdyt?

Note: I updated the More Info section in the Description to give some more context.

[IkerAlus]

So if pending_rewards can be used to reduce this, maybe it is worth re iterating. Wdyt?

Yes, that total makes sense. Bear in mind that this will simplify the logic from the relevant spec version onwards, but for previous ones, we will still need to maintain the more complex logic as introduced by #1445