rfc: generate client stubs from openrpc definitions

[aatifsyed]

• in [tracking] RPC refactoring wishlist #4032, I removed bindings for RPC endpoints in forest-cli attach, which is the integrated Javascript shell where users can make calls
• Define pattern for calling trait RpcMethod in forest-cli attach #4141 tracks defining a pattern for calling each of those methods

However, there are some downsides to that approach:

• we ship a JS interpreter :/
• we don't get nice autocomplete for structs
• it's awkward for users to use their own libraries in the shell

I propose we generate stubs from our OpenRPC definitions, and ship a client-as-a-library for users who want it. We delete forest-cli attach.

>>> import client
>>> forest = client.HttpClient("http://localhost:2345")
>>> forest.ChainHead()
TipsetLotusJson(Blocks=ForestFilecoinLotusJsonBlockHeaderBlockHeaderLotusJson(root=[{'Miner': 't01491', 'Ticket': ...
>>> type(forest.ChainHead())
<class 'client.definitions.TipsetLotusJson'>

This PR demonstrates

• Using datamodel-codegen to create types for python, with full auto-complete support in interpreters or your IDE:
  • 
  • There are some limitations to the generated definitions, where type information is lost. We might have to write some custom codegen here
• Using some rust code to generate a client interface, with typed methods

Outstanding questions

• Is this even better than forest-cli attach?
• How do we (regression) test this?#
• How do we do packaging/shipping?
• Do we really want to do the additional codegen we might need?

[hanabi1224]

I propose we generate stubs from our OpenRPC definitions, and ship a client-as-a-library for users who want it. We delete forest-cli attach.

Love this idea, boa-engine is a big dependency and ranks at the upper part of the build timings report.

[hanabi1224]

shall we include the requirements.txt

[aatifsyed]

Good question - added packaging/shipping as a TODO

[lemmih]

I like it. Can we test it the same way we currently test forest attach?

[LesnyRumcajs]

I'm okay with that, provided it's outside of the Forest repository. That way, it can live its own life, have possibly different owners and priorities when it comes to maintenance. What do you think @aatifsyed?

[aatifsyed]

I meant this PR as a sustainable transition away from forest-cli attach, allowing us to drop that code.

From discussion here and offline, I think you're saying:

• no-one will miss forest-cli attach
• if we want this to exist, it could (should) wait until there's demand - we're don't need more to maintain

In which case, we should

• tear out forest-cli attach
• drop this PR

[LesnyRumcajs]

I meant this PR as a sustainable transition away from forest-cli attach, allowing us to drop that code.

From discussion here and offline, I think you're saying:

• no-one will miss forest-cli attach
• if we want this to exist, it could (should) wait until there's demand - we're don't need more to maintain

In which case, we should

• tear out forest-cli attach
• drop this PR

To my knowledge, nobody will miss this feature, yes. It's been now quite some time since it was introduced, and I don't recall anyone using it.

I'm not saying we should completely drop this, but this should be a carefully considered decision. It does seem like an interesting thing to introduce to the ecosystem that may encourage people to tinker around more and prototype stuff. If we are okay with maintenance, let's do it, actively with all the best practices in mind. This means:

1. Setting up CI/CD
2. Testing
3. Release strategy
4. Docs
5. Considering our capacity with regard to maintenance and support.
6. Actively advertising it, so that it's actually used and doesn't end up as a pet project.

Otherwise, it's going to live in its own little directory, and folks will never hear about it. That is, let's do it right, or not at all.

Naturally, it's my subjective standpoint and shouldn't be considered a blocker.