Start Always Encrypted feature branch

[shueybubbles]

Fixes #107
Fixes #105
Fixes #104
Fixes #56

Key design tenets:

1. Key provider packages will sit outside the core module for apps to import as needed.
2. Decrypted column encryption keys will be cached for 2 hours by default. Key provider implementations can override the behavior by returning a zero duration to tell the driver not to cache its keys or by providing a custom duration.
3. Key provider implementations are registered globally. An application can provide a custom provider instance on a per-connection basis by adding it a Connector instance.
4. Key provider parameters are NOT available from the connection string. Each provider package must implement its own configuration management. For example - the globally registered AKV provider will use AzureDefaultCredential for authentication, which allows an app to control authentication through completely external means. Apps that want to use a ServicePrincipalCredential explicitly in code can attach an instance of the AKV provider to the Connector instead of relying on the globally registered instance. That technique will allow different credentials per connection.

Design issues to resolve in future PRs

1. How to implement inserts of encrypted data in an idiomatic way. The current app model relies on implicit type conversion from Go types to SQL types and the driver often relies on the server to coerce the input type to the column type. That type of conversion will fail for encrypted data, as the SQL type sent from the client has to be an exact match for the column type.
2. Proper analysis and management of the key cache. It could become a bottleneck depending on the type of mutex and the application workload. I am likely to implement 3 cache models based on each of the standard Go primitives - sync.Mutex, sync.RWLock, sync.Map so the application can choose which is appropriate for its workload. Such a model is likely to lead to apps being able to provide their own cache implementation.

[apoorvdeshmukh]

Looks good to me.
The testcase serves the E2E behavior but can we also add an example in the examples directory?

[apoorvdeshmukh]

Should we assert err to be nil for Read and Exec (incase dropping table fails)? #Closed

[shueybubbles]

there's not much the test can do if drop table fails.
If for some reason it does fail, the subsequent create table will fail with a duplicate name and the test will fail anyway

rand.Read won't fail

[shueybubbles]

Opened issue #142

---

In reply to: 1571828819