transaction rollback logic relied on exceptions, stripe charge function
signaled failure with Either, thus stripe failues had no effect on transaction
rollback

`catch` is not a good way to assert something is thrown

A POST to the charge endpoint is not actually a simple request according to
the CORS spec but this demonstrates that the CORS middleware at least fits in
place.

The next step is to replace simpleCors with a policy that's compatible with
use of our endpoint.

This is to make sure that we don't leak keys in the argument and hence
in logs etc.

let more "fixed" parameters come first and then the dynamic ones so
that one can do currying with the immutable parameters applied.

Stripe developer dashboard provides a few keys and we specifically
need to use the secret key.

If for "some reason" Stripe servers returned a mismatched voucher
code, return http 500 status.

Mark the voucher as paid if the stripe charge API returns a Charge
object.

The skeleton is in place, a lot of actual work still needs to be done.

Also, explode the tuple that made its way into `redeemVoucherHelper`

`redeemVoucher' reads stuff from the db, makes decisions and then
writes to the db. However if there is another client doing a
simultaneous `redeemVoucher' for the same `voucher', then both of them
would redeem the voucher, which is incorrect. The operations should
have exclusive access to the db and this is achieved with
`withExclusiveTransaction`.