Make HMAC signer thread safe

[tanner0101]

Makes HMAC JWT signers (hs256, hs384, hs512) thread safe (#117).

[MrMage]

Out of curiosity, how does the autoclosure change the method's thread safety behavior?

[vzsg]

Previously, the JWTSigner kept hold of the HMAC instance it was created with. As the HMAC context is not thread-safe, this made JWTSigner also not thread-safe (multiple calls to the same JWTSigner instance lead to EXC_BAD_ACCESS).

This issue is resolved by replacing the HMAC instance with a factory closure, so every signing/verification operation will create and use its own context.

With an @autoclosure annotation, this becomes a transparent change at build time instead of a source-breaking change.

(My two cents.)

[MrMage]

Thanks for the info. Two more questions:

1. This method seems to be called with e.g. an argument of HMAC.SHA256. What exactly does that evaluate to? If HMAC.SHA256 is a fixed reference, wrapping it in an @autoclosure would still return the same instance over and over again.
2. If I evaluate an @autoclosure twice, will the "wrapped" code be executed twice? I haven't tested that myself, but that would need to be true for the factory to be called twice, I guess.

[tanner0101]

1: HMAC.SHA256 is a computed method so each call gives you a new one back.
2: Yes, @autoclosure basically just wraps { return ... } around the argument. So hmac(HMAC.SHA256) is interpreted as `hmac({ return HMAC.SHA256 }). Each time you call that closure it will run the code inside.

[MrMage]

1: HMAC.SHA256 is a computed method so each call gives you a new one back.
2: Yes, @autoclosure basically just wraps { return ... } around the argument. So hmac(HMAC.SHA256) is interpreted as `hmac({ return HMAC.SHA256 }). Each time you call that closure it will run the code inside.

Sounds great, thank you for the elaboration! I would suggest documenting this use of @autoclosure with a short comment to document the purpose it serves in this case.