Allow multiple delegates.

[arik-so]

This PR modifies server behavior to return the content of the first delegate it finds, absent which it returns the inscription's own content.

[arik-so]

I'm really worried about this being a DoS vector. It would be fairly trivial to inscribe something with a couple thousand non-existent delegates. Any thoughts on whether it's a) a non-issue, b) makes the multi-delegate approach altogether unviable, or c) there are some mitigating strategies? @raphjaph

[cryptocj]

Can we add a limit number to avoid the Dos concern?
And extract a function to remove the repeat code below.

fn find_inscription<'a>(delegates: &'a [usize], index: &'a Index, max_length: usize) -> Option<&'a Inscription> {
    delegates
        .iter()
        .take(max_length)
        .find_map(|delegate| index.get_inscription_by_id(*delegate).unwrap_or(None))
}

// Usage
let inscription_override = find_inscription(inscription.delegates(), &index, max_length);

[arik-so]

Of course, the question is just what the limit should be. That's why I think @casey or @raphjaph should weigh in.

[arik-so]

This PR needs a test that, on the one hand, would allow the creation a custom inscription witness with multiple delegates, while on the other hand allowing to query the /content API endpoint.

The difficulty lies in the fact that Inscription::to_witness and InscriptionId::value are only available in ord::src, whereas TestServer is only available within ord::test. It seems like an inelegant merging of responsibilities to publicly expose the inscription-related methods, or to copy TestServer into ord::src, so if this is worth pursuing, I'm open to creative suggestions from the maintainers.

[casey]

I think this is fine, and I'm not to worried about the DoS potential. If it becomes a problem because someone created an inscription with a million delegates, we could just introduce a cap on the number of delegates that ordinals.com will respect. We could also be proactive, and limit it to, say, ten delegates, and just ignore any after that.

We've talked about recursive delegates before, see #2922. And I guess this probably works fine with that.

However, I'm not totally sure I understand the motivation for this feature. Can you open an issue to discuss it and tag me? I want to make sure that I understand what problem this solves or benefit it adds, and that whatever we do is the best possible solution.