Feature add indexed recursive inscriptions endpoint

[twosatsmaxi]

Fixes #3923

• [x] Added tests
• [x] Lint

[twosatsmaxi]

@casey @raphjaph can someone review it?

[elocremarc]

Upon further review I don't think there is any benefit of limiting ourself to using the Struct ChildInscriptionRecursive this is from the newer child endpoint which is a more optmized child endpoint that uses less onchain data. This struct was made for quick pagination at the cost of data for speed. Considering we are only returning the info of a single inscription we can afford to return everything about that inscription and use the InscriptionRecursive struct from /r/inscription

If we used InscriptionRecursive we would gain content_type content_length delegate value address

https://github.com/ordinals/ord/pull/3771#issue-2310319064

[elocremarc]

Upon further review I don't think there is any benefit of limiting ourself to using the Struct ChildInscriptionRecursive

On second thought I think we should only return the ID. @casey @raphjaph do you agree? This is redundant data from /r/inscription. Its useful on /r/children/:inscription_id/inscriptions because it returns 100 inscriptions with data. However this is only returning info about one inscription.

[twosatsmaxi]

@raphjaph can you have a look once?

[twosatsmaxi]

@casey @raphjaph: still waiting for the review.

[wagedu]

Upon further review I don't think there is any benefit of limiting ourself to using the Struct ChildInscriptionRecursive

On second thought I think we should only return the ID. @casey @raphjaph do you agree? This is redundant data from /r/inscription. Its useful on /r/children/:inscription_id/inscriptions because it returns 100 inscriptions with data. However this is only returning info about one inscription.

I'm a bit confused with the lack of hype for address info in general. Considering it's the 1st thing listed right after the ID, on any inscription page... I'd vote for the whole data in the 100 children. My current case as example: 4 inscriptions with 100 children each. But instead of 4 queries, it necessitates 400 queries, to compare addresses.

[twosatsmaxi]

@raphjaph @casey can you have a look once and also what do you think about comments by @elocremarc? would like your inputs too before going ahead make those changes, makes sense too me. The PR has been open since more than a month, would appreicate your reviews.