Refactor NewClient with options pattern

[jason-zhj]

Describe the change
Some organisations may have their own GPT proxy, so when using this library, they would need to specify their proxy url. In this case, seems NewClientWithConfig is the only function that they can use, but right now the authToken field in ClientConfig is not exposed, so they won't be able to pass in auth token.

Describe your solution
Refactor NewClient to use options pattern, so that user can use it with custom configs

Tests
Added new unit tests.

Issue: 480

[codecov]

Codecov Report

Merging #481 (7f93f7f) into master (a14bc10) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #481      +/-   ##
==========================================
+ Coverage   97.07%   97.16%   +0.08%     
==========================================
  Files          17       18       +1     
  Lines         719      741      +22     
==========================================
+ Hits          698      720      +22     
  Misses         15       15              
  Partials        6        6              

Files Changed	Coverage Δ
client.go	100.00% <100.00%> (ø)
options.go	100.00% <100.00%> (ø)

[vvatanabe]

@MarkusZhang

FIY We can already.

cfg := openai.DefaultConfig("openai_api_key")
cfg.BaseURL = "proxyUrl"

[jason-zhj]

@vvatanabe Oh thanks for telling, but this kinda unintuitive for the users IMO

[jason-zhj]

@vvatanabe Hi, I did a refactoring on NewClient method, by using the options pattern. It makes it very intuitive to the users what input is compulsory, and what is optionally configurable. This does affect any existing usage. Please help review again. Thanks

More about options pattern: https://golang.cafe/blog/golang-functional-options-pattern.html

[sashabaranov]

Hey, thank you for this PR. A similar approach was previously discussed here: #414 (comment)

The problem with setters is poor discoverability. You'll need to search through all With**** methods exposed by the library and figure out whether they are usable for configuration use cases. At the same time, the doc for config struct is neatly available in a single place https://pkg.go.dev/github.com/sashabaranov/go-openai#ClientConfig

[jason-zhj]

@sashabaranov Thanks for the reply, I think using struct is perfectly ok, but then why not expose the authToken field as AuthToken? Having to call DefaultConfig first, and then setting the fields really doesn't seem intuitive

[sashabaranov]

@MarkusZhang You are right, it's less intuitive, but prevents token to be accidentally leaked.

[jason-zhj]

@sashabaranov could you elaborate a bit more? As in leak to who? what issue do you envision?

[sashabaranov]

@MarkusZhang basically you can accidentally log the client struct and have auth token printed out

[jason-zhj]

@sashabaranov Ok, then. what about this:

type Config struct {
	BaseURL              string
	OrgID                string
	APIType              APIType
	APIVersion           string                    
	AzureModelMapperFunc func(model string) string 
	EmptyMessagesLimit uint
}

func NewClientWithConfig(authToken string, config *Config) *Client {
  // initialise client ....
}

Then we change ClientConfig to be for the library's internal use only, this way it's more intuitive to use and won't have the accidental logging issue