GODRIVER-2109 Prevent a data race between connecting and checking out a connection from the resourcePool.

[matthewdale]

GODRIVER-2109

There is currently a data race on the field connection.desc between setting it at connection.go#L231 and reading it at pool.go#L199 and pool.go#L535. The data race occurs when the resourcePool.Maintain() function adds connections to satisfy minPoolSize (only when minPoolSize > 0). The unconnected connections are added to the resourcePool and then connected in a separate goroutine, which results in concurrent access to the connection.desc field when another goroutine attempts to get the connection from the resourcePool.

Changes:

• Add a mutex to connection that guards access to the desc field, preventing a data race between setting and reading the value.
• Add a test that triggers the data race when run with the data race detector enabled.

Note that the logic for determining if a connection is stale based on the poolGenerationMap is intentionally unchanged. There is currently no way to know exactly what state a connection is in while conn.connected == connected without waiting for conn.wait(), which may take an indefinite amount of time. Instead, we preserve the existing behavior until the refactor in GODRIVER-2038.

[divjotarora]

LGTM if this resolves the data race.

[kevinAlbs]

LGTM, and thank you for the explanation of the issue in the description.

Note that the logic for determining if a connection is stale based on the poolGenerationMap is intentionally unchanged. There is currently no way to know exactly what state a connection is in while conn.connected == connected without waiting for conn.wait(), which may take an indefinite amount of time. Instead, we preserve the existing behavior until the refactor in GODRIVER-2038.

I do not fully understand why the staleness check occurs before the connection is connected. But I believe the change set here solves race described.