Refactor LookupID* APIs in StateManager and StateTree

[masih]

Related Issues

• Index Actor Events by ID #11594

Proposed Changes

The naming of LookupID can cause confusion when resolving actor IDs vs
ID addresses. To avoid this:

• Refactor StateTree LookupID to LookupIDAddress, because it returns ID address.
• Refactor StateManager LookupID to LookupIDAddress because it also returns ID address via a chain call to StateTree.
• Introduce a new API StateManager dedicated to resolving address to actor ID, called LookupID which returns abi.ActorID.

Additional Info

For context, see:

• feat: events: Index events by emitter actor ID #11723 (comment)

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• If the PR affects users (e.g., new feature, bug fix, system requirements change), update the CHANGELOG.md and add details to the UNRELEASED section.
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[rvagg]

sgtm

It has me wondering whether we should have a label, or some other way to identify breaking changes so we can keep them separate and call them out specifically. The distinction between breaking code API changes vs breaking RPC API changes also seems worth separating out too, because this change is going to be much less impactful than an RPC API change. @rjan90 what do you think? Maybe at a minimum we should ensure we add a CHANGELOG entry in a PR like this to call out the change for anyone using lotus as a library.