CSHARP-5205: Add option to configure DEK cache lifetime

[papafe]

No description provided.

[papafe]

@sanych-sun there are two things I'm not super convinced:

• Naming. Is DekCacheLifetimeMs a good name for the property? Internally this is called sometimes "dek cache lifetime", other times "key expiration" or "cache expiration". I used DekCacheLifetimeMs as it seems the most descriptive, but I'm open to possibilities.
• Constructors. Both ClientEncryptionOption and AutoEncryptionOption have public constructors with optional parameters, and if we want to keep binary compatibility we can't simply add a new optional parameter to the same constructor or add another constructor with the optional param (otherwise the compiler does not understand which constructor to use). For now I've added methods to both classes to the cache lifetime, but I'm not convinced by this since it is a different flow from the other parameters, and also this means that the property is not readonly anymore. The other possibility would be maybe to add another constructor in which the cache lifetime is one of the non-optional parameters, but I'm also not super fan of this.
  Any suggestions/ideas regarding those two?

(I also need to add input validation to be sure that the number of milliseconds isn't negative)

[damieng]

Is there a compelling reason to use a long here instead of a TimeSpan? .NET typically prefers TimeSpans for durations as they're easier to configure in terms of code and you don't need suffixes then like "Ms" on the end.

[papafe]

I think the issue here would be that TimeSpan has a greater granularity (microseconds) than the corresponding input for libmongocrypt (milliseconds).
We could also approximate the value if microseconds are used, but I'm not super convinced. I agree that maybe it would be easier to read with TimeSpan, even though more verbose.

[sanych-sun]

I suppose we should use TimeSpan. And pass TotalMilliseconds portion of it to libmongocrypt.

[papafe]

We could, or we could also throw an exception if there is microseconds.

[sanych-sun]

I suppose we should use TimeSpan. And pass TotalMilliseconds portion of it to libmongocrypt.

[sanych-sun]

What Dek means? Is property name prescribed by spec? I saw we call mongocrypt_setopt_key_expiration method after all. Should we name the property as simple as KeyExpiration?

[papafe]

DEK is the data encryption key. We can also call it KeyExpiration, I was just worried it could be too generic given the number of keys involved in the encryption, but I suppose it could be only this one if set up locally

[papafe]

@damieng @sanych-sun I've changed the name to KeyExpiration and used TimeSpan for its type.
I'm still not sure about the public API. In particular the constructors (copied from my previous message).
Both ClientEncryptionOption and AutoEncryptionOption have public constructors with optional parameters, and if we want to keep binary compatibility we can't simply add a new optional parameter to the same constructor or add another constructor with the optional param (otherwise the compiler does not understand which constructor to use). For now I've added methods to both classes to the cache lifetime, but I'm not convinced by this since it is a different flow from the other parameters, and also this means that the property is not readonly anymore. The other possibility would be maybe to add another constructor in which the cache lifetime is one of the non-optional parameters, but I'm also not super fan of this.