Add sat recursive endpoints with index and pagination

[raphjaph]

This PR takes the discussion from #2452 and implements the following recursive endpoints:

/r/sat/:sat -> get the first 100 inscription ids on a sat (ascending reinscription order)
/r/sat/:sat/:page -> get 100 inscription ids on sat paginated (ascending reinscription)

These two endpoints return:

{
  "ids": [ 
    "c3a05e88abd51708954ce562389478028567184e32fb96ab8d07b672989155b8i0", 
    "c3a05e88abd51708954ce562389478028567184e32fb96ab8d07b672989155b8i1"
  ],
  "page": 2,
  "more": false,
}

/r/sat/:sat/at/:index -> get a single inscriptions id on a sat by index (-1 is latest, 0 is first inscription)

This returns:

{  
  "id": "c3a05e88abd51708954ce562389478028567184e32fb96ab8d07b672989155b8i0", 
}

:sat can be any represenation of a sat including number, degree or letter notation.

Originally this PR would allow to use any sat notation like degree or percentile. For now we only accept the sat number.
#2732

[elocremarc]

Should shorten route name to save bytes.

[elocremarc]

Why are we doing /r/sat/:sat/at/:index
at is to many bytes its not needed and why are you disregarding my PR? This pretty much kills my entire motivation to help at all on this repo kinda a little frustrated right now to be honest because I worked hard on that PR and you just go do your own.

[casey]

Why are we doing /r/sat/:sat/at/:index at is to many bytes its not needed

We have three routes: Get inscriptions on a sat, get inscriptions on a sat with page index, and get a single inscription on a sat by index.

We were discussing names today, and the three names that we thought were best are:

/sat/:sat # get first page of inscriptions on a sat
/sat/:sat/:page # get `page` of inscriptions on a sat
/sat/:sat/at/:index # get a single sat at an index

We thought /sat/:sat/at/:index was a less ambiguous option.

and why are you disregarding my PR? This pretty much kills my entire motivation to help at all on this repo kinda a little frustrated right now to be honest because I worked hard on that PR and you just go do your own.

I understand your frustration, but opening a PR is not a guarantee that it will be merged, and not a guarantee that someone else won't open and merge a PR for the same functionality. Sometimes PRs would be hard to get into mergable shape, so we will write our own, when we want to get the feature out quickly.

Raph and I are super rate limited, we have an infinite amount of stuff to do, and very limited bandwidth to do it. I'd like to do better with this in the future. I don't know what the best way to handle this is, in general. We want to welcome contributions and contributors, but we have to prioritize getting ord into the best shape possible.

[elocremarc]

We thought /sat/:sat/at/:index was a less ambiguous option.

Isn't that what documentation is for it uses zero blockspace? We had a lot of discursion of reducing the byte limit the sat number already takes up quite a bit of characters.

Sometimes PRs would be hard to get into mergable shape, so we will write our own, when we want to get the feature out quickly.

Understood glad I was able to help move this discussion along opening a PR.

We want to welcome contributions and contributors, but we have to prioritize getting ord into the best shape possible.

How do we get people up to speed so their PRs can be closer to being mergable? Some of it might take a bit of hand holding and a bit of bandwidth however the more people we get familiar with the codebase the better this will become. Streams are a big help.

[elocremarc]

        .route("/r/sat/:sat", get(Self::sat_inscriptions))
        .route("/r/sat/:sat/:page", get(Self::sat_inscriptions_paginated))
        .route("/r/sat/:sat/at/:index", get(Self::sat_inscription_at_index))

I see now that /r/sat/:sat/:index would clash with the pagination route hence the /at/. Is the first route needed? Can we not bring back the sat info to get the output of the sat with that one? Because you can get at the 100 with the page route however this kind of closes off having sat info in the future if we ever want to add that. I think knowing the output(satpoint) is very desirable and non deterministic.

[casey]

We were thinking of adding something like /r/location/:sat to get the current location of a sat.

[elocremarc]

We were thinking of adding something like /r/location/:sat to get the current location of a sat.

/r/info/:sat Do we not want to add rarity or date? Can you find rarity with a JS library? Date could be cool to make a gallery of older sat inscriptions. Info is also shorter. I know we don't want to make an API however for web scrapers so I see the balance with that decision of limiting the info returned.

[casey]

Rarity and date can both be calculated with a JS library, so I don't think we'd add them.

[elocremarc]

We were thinking of adding something like /r/location/:sat to get the current location of a sat.

LGTM then! location can be added later I think. Or we could maybe just get that info with the /r/inscription/:id recursive route. See #2628

[casey]

LGTM!