Add a caching layer for NSSDB per-attribute keys

[simo5]

Adds a caching layer to NSSDB to reduce the performance impact of the key derivation operations.
NSSDB uses a particularly costly operation (pbkdf2) to derive a key for each of the attributes being encrypted.

This PR also adds a test to demonstrate the issue.
This test takes a relatively long time to execute without the cache:

$ time cargo test --features standard,nssdb test_nssdb_key_cache
   Compiling kryoptic v0.1.0 (/home/remote/ssorce/devel/git/kryoptic)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 4.96s
     Running unittests src/lib.rs (target/debug/deps/kryoptic_pkcs11-0639a8933718ff9b)

running 1 test
test tests::nssdb::test_nssdb_key_cache has been running for over 60 seconds
test tests::nssdb::test_nssdb_key_cache ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 186 filtered out; finished in 110.29s


real	1m55.282s
user	1m57.233s
sys	0m0.649s

It is much faster with the cache:

$ time cargo test --features standard,nssdb test_nssdb_key_cache
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.03s
     Running unittests src/lib.rs (target/debug/deps/kryoptic_pkcs11-0639a8933718ff9b)

running 1 test
test tests::nssdb::test_nssdb_key_cache ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 186 filtered out; finished in 0.11s


real	0m0.166s
user	0m0.144s
sys	0m0.020s

Fixes #130

[simo5]

Added a patch to constraint the size of the cache, otherwise it could grow unbounded.
I chose an arbitrary limit of 128 keys. The logic can be improved later if it turns out there is some use case that can consistently cause thrashing

[simo5]

Immortalizing an epic failure:

---- tests::login::test_login stdout ----
thread 'tests::login::test_login' panicked at src/tests/login.rs:78:9:
assertion `left != right` failed
  left: 0
 right: 0

Will have to check next week why this test fails exclusively when dynamically built, it makes no sense to me.

[Jakuje]

This is basically dropping a random item from the BTreeMap as it is ordered. Is there some way to be able to drop the oldest item without too much complication, or this is the best approximation we can get?

[simo5]

Dropping the oldest item is just as good as dropping a random one, we have no way to know if the one we are dropping is useful or was a one off anyway.
We would have to store additional data to know which is oldest I believe, and that is more complicated and would require also more processing.
Ideally normal usage of the token does not involve hundreds of encrypted attributes.

[Jakuje]

This sounds weird. We get the new keys, we replace them in self and then throw away as with logout. Would not it be more straightforward just throw away both instead of doing the indirect removal of old keys by assigning new keys and then flushing them too?

[simo5]

No because I want to preserve the cache of the pin which is created when we store it.

If you look carefully at the code you'll see caches are never dropped except when we whole sale replace all keys in this function, which makes sense because a change of PIN will change all keys so all caches are useless.

[Jakuje]

lgtm