refactor(katana): remove starknet crate dependency from RPC client (#268)

## Summary

Removed dependency on the `starknet` crate from the Katana RPC debugging client and replaced it with Katana's native types, using `jsonrpsee` for proper JSON-RPC handling.

This new implementation will also help us better validate our own RPC types.

## Original Instructions

The user requested the following changes to the Katana RPC client:

1. **Remove all reliance on the `starknet` crate** - The RPC client implementation in `bin/katana/src/cli/rpc/client.rs` was based solely on types from the `starknet` crate
2. **Use Katana's own RPC types** - Replace starknet types with types from `crates/rpc/rpc-types/src`
3. **Replace HttpTransport with direct HTTP client usage** - Avoid using `HttpTransport` from starknet crate
4. **Return raw JSON responses** - The client should display the raw JSON response objects (not deserialize into proper types) as this CLI command is meant to be used primarily as a debugging tool to validate RPC server responses
5. **Use Katana's error types** - Use the Starknet API error types from `crates/rpc/rpc-api/src/error/starknet.rs`

## Evolution of Implementation

### Initial Implementation (First Commit)

Initially implemented a manual JSON-RPC client using `reqwest`:
- Created manual JSON-RPC request/response structs
- Used `reqwest::Client` directly for HTTP requests
- Manually handled JSON-RPC error conversion to `StarknetApiError`
- ~270 lines of code with significant boilerplate

### Improved Implementation (Second Commit)
After discussion, refactored to use `jsonrpsee` for cleaner JSON-RPC handling:
- **Uses `jsonrpsee::http_client::HttpClient`** - Proper JSON-RPC client with built-in protocol handling
- **Leverages `ClientT::request` method** - Returns raw `serde_json::Value` for debugging
- **Uses `ArrayParams`** - Type-safe parameter handling from jsonrpsee
- **Removed manual JSON-RPC code** - No more custom request/response structs
- **Better error handling** - jsonrpsee handles JSON-RPC errors automatically
- **~30% less code** - Cleaner, more maintainable implementation

### Final Refinement (Latest Commit)

Aligned the client method signatures with the existing starknet client:
- **Removed `to_json()` methods** - BlockIdOrTag/ConfirmedBlockIdOrTag
already implement Serialize/Deserialize
- **Updated method signatures** to match
`crates/rpc/rpc-client/src/starknet.rs` exactly:
- Use proper typed arguments (ContractAddress, StorageKey, ClassHash,
etc.)
  - Maintain raw `Value` return types for debugging purposes
- **Improved type safety** - Use FunctionCall struct directly instead of
manual JSON construction
- **Automatic serialization** - Let Serialize trait handle JSON
conversion

## Thought Process & Alternatives Considered

### Initial Approach

Initially planned to simply replace the `starknet` crate types with Katana types while maintaining the same client structure.

### Alternative Considered: Reusing `katana-rpc-client`

During implementation, we considered reusing the existing `katana-rpc-client` (at `crates/rpc/rpc-client/src/starknet.rs`) instead of maintaining two separate client implementations. This client:

- Already uses all Katana's native types
- Uses `jsonrpsee` with the trait-based API from `katana-rpc-api`
- Has proper error handling with `StarknetApiError`
- Would eliminate code duplication

### Why We Kept a Separate Implementation

After discussion, we decided to maintain a separate client implementation for the CLI debugging tool because:

1. **Different Purpose**: The CLI client is specifically for debugging and validating raw RPC responses, while `katana-rpc-client` is for programmatic use
2. **Raw JSON Output Required**: The user explicitly wanted to see raw JSON responses to validate server output, not deserialized typed responses
3. **Debugging Focus**: A simpler, direct implementation gives better control and visibility for debugging purposes
4. **Independence**: Having a separate implementation allows the debugging client to evolve independently without affecting the main RPC client

### Final Improvement: Using jsonrpsee

Realized that using `jsonrpsee` (already in the project dependencies)
would provide:

- Proper JSON-RPC 2.0 compliance
- Built-in error handling
- Less code to maintain
- Better compatibility with the rest of the codebase

## Final Implementation

- **Dependencies**: Removed `starknet` and `reqwest`, added `jsonrpsee` with `http-client` feature to `bin/katana/Cargo.toml`
- **RPC Client**: Uses `jsonrpsee` with proper typed method signatures matching the starknet client
- **Type Replacements**:
- `starknet::core::types::BlockId` →
`katana_primitives::block::BlockIdOrTag`
- `starknet::core::types::ConfirmedBlockId` →
`katana_primitives::block::ConfirmedBlockIdOrTag`
  - `starknet::core::types::BlockTag` → Direct enum variants
- `starknet::core::types::FunctionCall` →
`katana_rpc_types::FunctionCall`
- `starknet::providers::jsonrpc::HttpTransport` →
`jsonrpsee::http_client::HttpClient`
- ContractAddress, StorageKey, ClassHash, Nonce → All from katana_primitives
- **Updated `starknet.rs`**: 
  - Removed `to_json()` methods since types already implement Serialize
  - Uses BlockIdOrTag/ConfirmedBlockIdOrTag directly
  - Uses FunctionCall struct instead of manual JSON construction
- **Updated tests**: Changed test assertions to use Katana types

## Motivation

The RPC client in the Katana binary is primarily used as a debugging tool to validate RPC server responses. By removing the external `starknet` crate dependency and using Katana's own types with proper JSON-RPC handling via `jsonrpsee`, we:

1. Reduce external dependencies
2. Maintain consistency with the rest of the codebase
3. Have cleaner, more maintainable code
4. Get raw JSON responses for better debugging visibility
5. Ensure proper JSON-RPC 2.0 compliance
6. Achieve better type safety with proper method signatures

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: kariy

.tool-versions

@@ -0,0 +1 @@
+scarb 2.8.2

Cargo.lock

@@ -25,6 +25,7 @@ comfy-table = "7.1.1"
 const_format = "0.2.33"
 indicatif = "0.17.8"
 inquire = "0.7.5"
+jsonrpsee = { workspace = true, features = ["http-client"] }
 piltover.workspace = true
 rand.workspace = true
 shellexpand = "3.1.0"