api: add context to connection create

[DerekBum]

connection.Connect and pool.Connect no longer return non-working connection objects. Those functions now accept context as their first arguments, which user may cancel in process.

connection.Connect will block until either the working connection created (and returned), opts.MaxReconnects creation attempts were made (returns error) or the context is canceled by user (returns error too).

I didn't forget about (remove if it is not applicable):

• Tests (see documentation for a testing package)
• Changelog (see documentation for changelog format)
• Documentation (see documentation for documentation style guide)

Closes #136

[oleg-jukovec]

1. I've expect that a context could be used with a network connection call. We could use net.DialContext instead of net.Dial.
2. What do you thing about get rid of the opts.Reconnect logic with timeouts and retries inside the Connect()? We could use just a context object to handle the Connect lifetime and try to make the connection only once.

[DerekBum]

We are currently using net.diatTimeout:

go-tarantool/dial.go

Lines 201 to 212 in d8df65d

	// dial connects to a Tarantool instance.
	func dial(address string, opts DialOpts) (net.Conn, error) {
	network, address := parseAddress(address)
	switch opts.Transport {
	case dialTransportNone:
	return net.DialTimeout(network, address, opts.DialTimeout)
	case dialTransportSsl:
	return sslDialTimeout(network, address, opts.DialTimeout, opts.Ssl)
	default:
	return nil, fmt.Errorf("unsupported transport type: %s", opts.Transport)
	}
	}

I don't think we can use context from Connect call in this case (unless we ask the user to use contextWithTimeout to specify DialTimeout field).

[oleg-jukovec]

I don't think we can use context from Connect call in this case (unless we ask the user to use contextWithTimeout to specify DialTimeout field).

We could remove and don't use the opts.DialTimeout since we'll be using a more flexible context object.

[DerekBum]

NB: need to change go.mod and go.sum after the patch from go-openssl.

[oleg-jukovec]

The code is not the same as in the previous implementation. The previous implementation have a timeout by default. The current code have an infinity timeout.

So we need to use a context default timeout in all tests/examples/inner calls (or pass a context to it).

tarantool.Connect(context.Background(), server, opts)

[oleg-jukovec]

Thank you for the patch!

[oleg-jukovec]

Please, fix the problem and describe the fix/problem.

--- FAIL: TestAdd_CloseGraceful_concurrent (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x9a8cec]

goroutine 301 [running]:
testing.tRunner.func1(0xc000106400)
	/opt/hostedtoolcache/go/1.13.15/x64/src/testing/testing.go:874 +0x69f
panic(0xbe5d60, 0x111eb00)
	/opt/hostedtoolcache/go/1.13.15/x64/src/runtime/panic.go:679 +0x1b2
github.com/tarantool/go-tarantool/v2/pool.(*ConnectionPool).CloseGraceful(0xc00011e8c0, 0xc95140, 0xc000350520, 0xc00011e8c0)
	/home/runner/work/go-tarantool/go-tarantool/pool/connection_pool.go:335 +0x13c
github.com/tarantool/go-tarantool/v2/pool_test.TestAdd_CloseGraceful_concurrent(0xc000106400)
	/home/runner/work/go-tarantool/go-tarantool/pool/connection_pool_test.go:487 +0x44f
testing.tRunner(0xc000106400, 0xc95148)
	/opt/hostedtoolcache/go/1.13.15/x64/src/testing/testing.go:909 +0x19a
created by testing.(*T).Run
	/opt/hostedtoolcache/go/1.13.15/x64/src/testing/testing.go:960 +0x652
FAIL	github.com/tarantool/go-tarantool/v2/pool	5.065s

[DerekBum]

Yeah, that happened because of this race:

1. In Add we are adding an endpoint to the map (p.addrs[addr] = e) inside a protected code (with locked p.addrsMutex). But after that we unlock the mutex, call tryConnect and only after that initialize cancel() field for endpoint.
2. In CloseGraceful we are rlocking the p.addrsMutex and for each saved endpoint calling cancel() (may not be initialized).

So as a fix I did this: inside Add function initialize cancel in the protected part. In case of any error, we just cancel the created context.

Note: there is no problem with ConnectWithOpts, because we can't use the new pool until we return from the function.