feat: remove API secret in favor of explicitly passing user HMAC

[stigi]

Note

This PR supersedes #32

In this PR

This changes the way the Swift SDK handles user HMACs. Previously it was expected to pass the API secret so the client side SDK would calculate the HMAC. This is a bad practice and discouraged.

With this change the SDK only allows for a enableHMAC toggle, and an optional hmac parameter to the connectUser call.

Test Plan

I've tested the change in the Example app by using the API key from a project with Security enabled.
I've also extended the Example app so that one can provide an hmac when changing to a different user.

I could confirm that notifications did load when providing a correct hmac, while they returned console errors when no hmac was provided (added line breaks for readability):

{"errors":[{
  "code":"hmac_header_not_provided",
  "message":"HMAC header not provided",
  "suggestion":"Please provide the 'X-MAGICBELL-USER-HMAC' header containing the HMAC of the user's email. The HMAC is generated using the user's email/external_id and your MagicBell project's API secret.",
  "help_link":"https://www.magicbell.com/docs/hmac-authentication"}]}

When providing an invalid hmac the following error was provided (added line breaks for readability):

 {"errors":[{
  "code":"hmac_header_invalid",
  "message":"HMAC header should be Base64 encoded",
  "suggestion":"Please provide a valid Base64 encoded value for the 'X-MAGICBELL-USER-HMAC' header",
  "help_link":"https://www.magicbell.com/docs/hmac-authentication"}]}

Open questions:

1. Those errors are only bubble up in the console and the SDK seems to not provide a way yet to handle these errors in the client app
2. Is the enableHMAC flag on MagicBellClient actually needed? It could be deferred by whether an hmac is passed into connectUser. Also the truth whether hmac is enabled resides on the Magicbell project configuration on the server. Resolved in ba8e20d
3. The documentation on https://www.magicbell.com/docs/libraries/ios needs to be updated according to the changes in here.

[stigi]

Good that we have tests running again now. Looks like they just need to be updated.