Clients should accept messages secured by an expired SecurityToken

[svanharmelen]

I encountered a bug where an incoming message would fail with an invalid signature error. After quite some debugging I noticed this only occurred when the message was received just a few milliseconds after a security channel renewal.

After careful inspection it turned out that the message was still encrypted (which is according to spec) with the remote keys of the old security channel, but the client tried to decrypt and validate the message with the renewed keys.

According to the specs clients should accept messages secured by an expired SecurityToken for up to 25 % of the token lifetime (see https://reference.opcfoundation.org/Core/Part4/v105/docs/5.5.2 for more details), so I added a bit of logic to store the last 5 used remote keys and choose which one to use based on the token ID in the security header.

After making these changes and testing again against the same OPC UA server the issue did not occur again (while it occurred multiple times per hour before this fix was implemented) so this seems like a nice little improvement making the package a little bit more complaint.

[einarmo]

This is clearly something we need, but I'm not entirely sold on the approach, see comments.

[svanharmelen]

Updated the PR... It maybe just a little bit more involved, but it follows the spec for 100% this way.

Note that I removed the token_has_expired method as it contained a bug (used the lifetime as seconds instead of milliseconds) and wasn't used by any of the client or server code.

[einarmo]

I think this is a perfectly fine solution, but see my comment on timestamps. We should strongly prefer using std time for any internal mechanisms.