client: use long-lived streams for Append RPC

[ijsong]

In #449, we update the Append RPC from unary to stream. The client API will now establish a stream, send an AppendRequest, receive an AppendResponse, and close the stream. This change allows us to maintain the semantics of the Append API and simplifies the underlying code.

varlog/internal/storagenode/client/log_client.go

Lines 41 to 71 in 2cea668

	// Append stores data to the log stream specified with the topicID and the logStreamID.
	// The backup indicates the storage nodes that have backup replicas of that log stream.
	// It returns valid GLSN if the append completes successfully.
	func (c *LogClient) Append(ctx context.Context, tpid types.TopicID, lsid types.LogStreamID, data [][]byte) ([]snpb.AppendResult, error) {
	ctx, cancel := context.WithCancel(ctx)
	defer cancel()
	stream, err := c.rpcClient.Append(ctx)
	if err != nil {
	return nil, err
	}
	defer func() {
	_ = stream.CloseSend()
	}()
	req := &snpb.AppendRequest{
	TopicID: tpid,
	LogStreamID: lsid,
	Payload: data,
	}
	err = stream.Send(req)
	if err != nil {
	return nil, err
	}
	rsp, err := stream.Recv()
	if err != nil {
	return nil, err
	}
	return rsp.Results, nil
	}

Making a new stream for every API call is inefficient, leading to repeated RPC initiation.
According to gRPC best practice, we can improve it by reusing long-lived streams. To do that, we need to change the client Append API.