[SDK] Decouple pkg/sdk from the poktroll repo

[Olshansk]

Objective

Decouple pkg/sdk to prepare for a full-time owner of the Shannon SDK

Origin Document

Note: not all of these are publically accessible

• SDK Documentation
• SDK requirements protocol/backend collab
• Initial Poktroll SDK notion doc
• Grove's Portal POC integration with the Shannon SDK in this PR

Goals

• Prepare Shannon POC SDK to be transferred to a full-time owner
• Enable any gateway current/future gateway to easily interoperate with Shannon

Deliverables

• 1. Move pkg/sdk into its own repository called pocket-shannon-go and update poktroll to depend on it
• 2. Make storage and network statefullness configurable in the new SDK
  • 2.1 If this deems more than a few hours of work, remove it altogether while making sure poktroll still works.
• 3. Remove as many cosmos dependencies as possible (e.g. depinject) as longs as its straightforward.
  • 3.1 Leave TODO_DECOUPLE if it's non-trivial. Goal 1 is the top priority

Technical notes/considerations for future SDK owners

• The new SDK should be viewed - conceptually - as a replacement for pocket-go
• Frameworks like fern can be used to generate SDKs on a per language basis at a cost of $10,800/year/language.
  • Cons: It'll require heavy pocket-specific customizations
  • Pros: We can get other languages (e.g. javascript, python) using the same flow to get replacements for things like pocket-js
  • Potential investigations: We can potentially leverage the open-source tools underlying fern to do this ourselves. See the discussion here.
• Frameworks like gendocu could be used for automating grpc documentation
• The modern Cosmos SDK uses gRPC instead of OpenAPI as the source of truth
  • If you search for service across all *.proto files in this repo, they will come pop up and be viewed as the source of truth
  • docs/static/openapi.yml contains a swagger-compatible OpenAPI spec but should not be seen as the source of truth
• Need to look into why
  gateway-server didn't use pocket-go as they should (theoretically) be using the new SDK

Non-goals / Non-deliverables

• Anything that's detailed out in the future owner section above

General deliverables

• Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• Testing: Add new tests (unit and/or E2E) to the test suite.
• Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @Olshansk
Co-Owners: @red-0ne @moatus

[Olshansk]

[red-0ne]

Close with #554 and #594