fix/http-trigger-with-encrypted-body

[brian-mulier-p]

closes #104

[brian-mulier-p]

@loicmathieu & @anna-geller I'm unsure it's the way we want to handle this issue. Basically the old version isn't working as we have an encryptedBody the whole way long (meaning that even in responseCondition we should use encryptedBody) but we don't decrypt it before evaluating the responseCondition.

We can keep that behaviour but add a decrypt step (however it would imply that we move the decrypt method visibility to public in RunContext @loicmathieu) or do as I did here where we execute the request without asking to encrypt body, then we encrypt it before creating the execution from trigger.

The only con I see with that is the discrepancy for reaching out the body as responseCondition is positioned before the encryption (so we reach it out with .body) while in tasks we get a .encryptedBody from trigger variable

[brian-mulier-p]

@anna-geller FYI after discussion with Loïc, we came to the point that it wasn't a security issue to put decrypt method as public in the runContext which allow the trigger task to keep calling Request task with encrypted body and decrypt it on the fly before evaluating the responseCondition