Segmentation fault on parsing `Date`

[ionut-arm]

When requesting StartDate or EndDate attributes on a key we get a segmentation fault. For example, running the following unit test:

#[test]
#[serial]
fn aes_key() -> Result<()> {
    let (pkcs11, slot) = init_pins();

    // set flags
    let mut flags = SessionFlags::new();
    let _ = flags.set_rw_session(true).set_serial_session(true);

    // open a session
    let session = pkcs11.open_session_no_callback(slot, flags)?;

    // log in the session
    session.login(UserType::User, Some(USER_PIN))?;

    // get mechanism
    let mechanism = Mechanism::AesKeyGen;

    // pub key template
    let key_template = vec![
        Attribute::Class(ObjectClass::SECRET_KEY),
        Attribute::Token(true),
        Attribute::Sensitive(true),
        Attribute::ValueLen(16.into()),
        Attribute::KeyType(KeyType::AES),
        Attribute::Label(b"testAES".to_vec()),
        Attribute::Private(true),
    ];

    // generate a key pair
    let key = session.generate_key(&mechanism, &key_template)?;

    let attributes_result =
        session.get_attributes(key, &[AttributeType::EndDate, AttributeType::StartDate]);

    match attributes_result {
        Ok(attributes) => println!("working with version: {:?}", attributes),
        Err(e) => println!("error getting attributes: {:?}", e),
    }
    Ok(())
}

results (for me) in a SIGSEGV.

[ionut-arm]

When a Cryptoki object carries an attribute of this type, and the default value of the attribute is specified to be "empty," then Cryptoki libraries SHALL set the attribute's ulValueLen to 0.

Seems SoftHSM2 at least return an empty date, so we have to add a check for that, and return a "default" value.

Note that implementations of previous versions of Cryptoki may have used other methods to identify an "empty" attribute of type CK_DATE, and applications that needs to interoperate with these libraries therefore have to be flexible in what they accept as an empty value.

And this is the spec giving us the finger and telling us that there's no way to know what "empty" actually means for older implementations :]