cardano-rpc | Use buf for code generation instead of cabal/protoc integration

[carbolymer]

Changelog

- description: |
    Use buf for code generation instead of cabal/protoc integration.
    Reenable cardano-rpc.
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
   - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...
# uncomment at least one main project this PR is associated with
  projects:
  # - cardano-api
  # - cardano-api-gen
   - cardano-rpc
  # - cardano-wasm

Context

Current state

In the previous version of cardano-rpc package, the code was generated during cabal-build which was prolonging build process and was pulling proto-lens-protoc into the dependency tree. This was prone to breakage and was causing complicated issues with cabal's dependency resolution.

The proposed solution

This PR changes that by using an external tool buf which allows to generate code from protobuf definitions for various languages. This should be extended for typescript/javascript code generation later.

The caveat here is that it includes generated files in the repository which have following effects:

• They increase diff sizes and thus repository size - this will be more significant once we decide to check-in code from more languages
• Generated files have to be kept in sync - this PR adds a GHA build step for that

The end goal is to not use generated code in the production code (or minimal amount of it), and rely on the packages provided by utxorpc:

• https://hackage.haskell.org/package/utxorpc
• https://www.npmjs.com/package/@utxorpc/spec

The ultimate purpose of keeping the generated code in the repository is the ease of work on proto files when one would like to introduce changes to proto definitions without having to go through utxorpc upstream, which is a time consuming process.

Alternatives

An alternative is to move the generated code using buf to a separate repository. The separate repository would be integrated by SRP only when it's needed.

Pros

More separation, smaller diffs. We would only have to rely on SRP for the period of working on new changes to proto files.

Cons

More detached work, changes to proto files less visible. Process of updating a separate repo is more time consuming.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[Jimbo4350]

LGTM. You need to fix CI and can you include some brief documentation as to how the files are generated using buf?