Added Option<Slot> to PKCS 11 Provider constructor

[Sven-bg]

Fix the issue #375

[ionut-arm]

Hi! 👋🏻

Thanks for the patch, the code looks good, but the "optionality" should be propagated to service spin-up: the slot number should be optional in the service configuration file as well, and have it passed down like that from the ServiceBuilder.

I'd also recommend "testing" it, either by removing the slot number from the config file we usually use for end-to-end tests, or by creating a new configuration test (the latter is probably better).

[Sven-bg]

Hi @ionut-arm if you prefer I can cancel the PR, add the requested changes and make a new one.
About the testing, I disccused it with @hug-dev and we agreed on applying the patch and later on add some new tests to cover this specific feature, but if you prefer, I can add the tests too.
Thank you for the hints.
Adriano

[ionut-arm]

No, keep the PR open and build on top of it/adjust the commits. And leaving the testing for another PR sounds alright!

[ionut-arm]

Actually, I'm wondering - should we do it this way, grabbing the "first" token, or should we fail if slots.len() != 1? My worry is whether the result is deterministic - what if there are two slots and you get them arranged at random? Have to admit, I've not looked at the spec too closely.

[ionut-arm]

(or, what if a new slot/token is added at some later point and that one becomes the first one? your service will spin up, but you'll essentially lose a lot of keys)

[hug-dev]

Yes that's a very good point and I think a good suggestion. I checked the PKCS 11 docs and nothing says that the order is deterministic but also because of the other reason you indicated I think it's better to check that there is only one slot to use.

So replacing the above with:

-if !slots.is_empty() {
+if slots.len() == 1 {

We should make it clear that this behaviour is used in the config file comments.

[hug-dev]

Thanks, that will be useful! A few comments added.
You might need to cargo fmt before sending it again, when parallaxsecond/rust-cryptoki#35 is merged and imported here!

Next step would be to write a test, but that's totally something we can handle ourselves!