Have Authorization for deletion of messages

[LeonFLK]

fixes KILTProtocol/ticket#719

fixes KILTProtocol/ticket#685

Adds header authorization as signature key to the message delete route, to restrict message deletion to receiver of the message.

If you want to delete a specific message with the messageId, supply the with the receiver identity signed messageId inside headers as signature key.

Checklist:

• I have verified that the code works
• I have verified that the code is easy to understand
  • If not, I have left a well-balanced amount of inline comments
• I have left the code in a better state
• I have documented the changes (where applicable)

[rflechtner]

I like the idea of restricting messages to the in / outbox; however the authentication scheme of signing your address is trivial to circumvent and could encourage bad practice in the worst case. Because we sign the same string every time, anyone intercepting a successful request could again request all of this addresses incoming and outgoing messages. If we're serious about this, we'd need to answer a challenge sent by the server as they do in the HOBA scheme or SCRAM. Of course this would be quite a bit more work... maybe there is already a next.js implementation for that out there? BTW are we following HTTP authentication specs here or are we being creative? (I'd love to see some integration tests to understand what a request for this would look like).
The scheme may be more secure when signing a unique message id for deletion, which is a one-off operation. Re the implementation, I'd propose you add a findById method to the message service, then handle the authentication stuff on the controller - my intuition tells me that's where those kinds of things belong.

[rflechtner]

Signing a date header with the current time as proposed here may be a low-effort solution that is a bit more secure?

[LeonFLK]

We don't care about inbox and outbox, we only care about authorizing the delete of a message.
For now we are going to stick to this approach, and are going to change this when we adopt DIDcomm or other means of authorization and security.

[rflechtner]

LGTM, just throw out the yarn.lock changes pls! And maybe have another look at the error string with which we respond to unresolvable signatures.

Requested changes implemented