refactor(sdk): refactor Go SDK client

[chengxilo]

---

Edited in July 2, 2025 (GMT-4), to reflect the latest change.

Description

What I did

1. Refactored the Go SDK client creation logic using the option pattern.

2. Updated the client interface and TCP client methods to align closely with the Rust SDK:

   • Replaced struct-based parameters with explicit argument lists.
   • Used pointers to represent optional arguments.
   • Edited some return type to align with rust sdk.

3. Changed all related tests to reflect the updated interface and logic.

Future work

The goal of this PR is to align the API surface and usage pattern with the Rust SDK — not to fully implement every internal behavior. Since there are some logic not implemented yet, I add some TODO in those part.

---

Some explanation (Outdated, kept for history)

What I did

1. refactor logic for building new Go SDK client using builder pattern
2. I changed some function to make them align with Rust SDK ( not only their name, I also edited part of their output)
3. I updated the tests.

Why we need to refactor it.

( I copied the message I sent in discord a few days ago here)
Since currently, the golang sdk is very out dated and when we create a client the
in rust when we create client:

let client = IggyClientBuilder::new()
        .with_tcp()
        .with_server_address(get_tcp_server_addr())
        .build()?;

While in golang we create client:

factory := iggy.IggyClientFactory{}
msgStream, _ := factory.CreateMessageStream(iggcon.IggyConfiguration{
    BaseAddress: "vm:8090",
    Protocol:    "tcp",
})

Since the Rust SDK is considered the primary or canonical implementation, it makes sense for other language SDKs to follow its design principles closely — including using the same repository name and similar function names. Clearly, the current Go SDK does not meet this requirement: its function names don’t clearly describe their purpose, and the overall design pattern feels less elegant.

My solution

So what I did is to read the rust sdk source code and ... almost directly ported its logic to Go. I want to explain why I decided not to use the option pattern discussed earlier with @haze518, even though the option pattern is commonly considered best practice in Go. At first, I choose to follow the example of https://github.com/nats-io/nats.go/blob/main/nats.go#L867 . It's elegent, but it would not work so well in our use case, since we need to support tcp/http/quic three different protocol and they have different options.
Here is a simplified example showing the potential issue:

package main

type Options struct {
	protocol string
	aTcpOpt bool // a TCP-specific option
	aHttpOpt bool // a HTTP-specific option
}
type Option func(*Options)

func WithTcp(opts *Options) {
	opts.protocol = "tcp"
}
func WithHttp(opts *Options) {
	opts.protocol = "http"
}
func WithATcpOpt(opts *Options) {
	opts.aTcpOpt = true
}
func WithAHttpOpt(opts *Options) {
	opts.aHttpOpt = true
}
func New(opts ...Option) {
	options := &Options{
		protocol: "tcp",
		aTcpOpt:  false,
		aHttpOpt: false,
	}
	for _, opt := range opts {
		opt(options)
	}
	// ... build the client with option
}

func main() {
	New(WithTcp, WithAHttpOpt, WithATcpOpt) // user may add a http option when they are using tcp
}

So, I think it is not a good choice as I don't know how to solve this problem while using option pattern. But if we use builder pattern, it allows us to control and constrain users’ choices more effectively, preventing invalid combinations and leading to a cleaner, safer API.
so currently, after this pr, the usage of it would be:

func main() {
    cli, err := iggycli.NewIggyClientBuilder().WithTcp().WithServerAddress("127.0.0.1:8090").Build()
    if err != nil {
        panic(err)
    }
    // use cli
}

[chengxilo]

All function signatures and return types have been updated. Required arguments are passed directly, while optional arguments are represented as pointer values. I try to limit the scope of changes in this PR to function signatures and their usage logic, as this pr is already too huge. However, I had to modify some functions—mainly in the serialization layer—to align with the updated argument and return value structure. For more detail. Please check the comments I provided in review.