[rpc-alt] implement getCoinMetadata method

[emmazzz]

Description

This PR implements the getCoinMetadata method.
It also fixes a subtle bug in load_live that prevented us from loading non-address-owned objects.

Test plan

Added a test.

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• Protocol:
• Nodes (Validators and Full nodes):
• gRPC:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 25, 2025 9:58pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Feb 25, 2025 9:58pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Feb 25, 2025 9:58pm

[emmazzz]

This was pretty hard to find -- turns out owner_id is None when the object is frozen or shared!

[amnn]

It may work better to introduce a new data loader for singleton objects -- it would be keyed on TypeTag, and it would run a query something like (my syntax might be a bit off):

SELECT DISTINCT ON (package, module, name, instantiation)
    object_id,
    owner_kind
FROM 
    obj_info
INNER JOIN (
    VALUES 
        (...), ...
)   types (package, module, name, instantiation)
USING (package, module, name, instantiation)
ORDER BY
    package,
    module,
    name,
    instantiation,
    cp_sequence_number DESC

...and then it can filter out results where the owner_kind is NULL in memory, because there will be at most one for each input type.

Keeping singleton object queries separate lets us take advantage of the fact that they can be batched, and keeps the owned object filtering path simple as well.

At the moment, I'm concerned by this conditional -- we can do the work now to make sure that fetching coin metadata is efficient, but it implies that any combination of filters plus owner_kind IS NOT NULL is going to be efficient, and I'm less sure about that, because it isn't exactly covered by one of our indices, and the only reason that's okay for CoinMetadata is because we know that there should be at most one result for each type, which makes it cheap to filter that out with a scan -- this won't be true in general.

[emmazzz]

I agree with separating out fetching singleton object and have done so in the new commit.

The query doesn't work though because, for a deleted object, not only is owner_kind null, all the type fields are null too so we have to stick to the consistency query style. I didn't want to make this a data loader because dealing with multi fetching for a vector of types will be much harder than fetching for one type and I don't want this to become a blocker. I have added a TODO for it though.

[amnn]

Nice find!