working yet)

- logging debug capability
- payment /pay route
- handles helloasso intent
UNSTABLE, far from working as indented

transaction and remove pagination

- Centralize amount calculation in a function of the `Transaction` model
- Add admin entries for Transaction and Product, and tweak the
  Transaction form so that it can compute the amount itself on save.

  NOTE: currently, if you save and keep editing, the amount will not
  change. See #69

Use a M2M through table that also stores the amount of each product used
in a transaction, sorting out the issue of not being able to have
duplicate entries for a product in a Transaction.

Implement the basic logic that verifies that a payment succeeded or
failed on the main return path provided by HelloAsso.

Change the ordering of headers and fix a typo in payment models (typo is
in the payment status for a transaction)

Introduce:
- Product category, that allows the system to know what category the
  product belongs to
- Associated tournament, a potential foreign key to a tournament when
  the product is a tournament registration
- Allow a product to be a null key in a ProductCount pair, and set it to
  null when it is deleted

This commit introduces the product category hook system, which allows
applications to create a class derived from an interface that implements
callbacks for payment success and failure handling.

A module can simply inherit the `PaymentHooks` class in one of its
classes, and register it with the `PaymentCallbackSystem` class.

An example is provided with the tournament class, which now implements a
way to validate a pending registration with a payment.

Show all fields introduced earlier in the product admin page

In the payment API, when a payment is initiated, call the preparation
hooks of a payment hook class. In the return view, call the accept
hooks.

Models in the tournament field are modified thusly:
- The whole file is formatted
- A team is now always attached to a tournament, including when it is
  not validated. A boolean is added in `Team` to know if it has been
  validated
- Both player and manager registrations now have a foreign key to their
  ticket, which is null until the payment of their ticket has succeeded
- Admin view updated
- Tests updated

Move payment callbacks in the transaction model, such that all of the
iteration work is abstracted away from views. Also add the "id" field of
a product to be shown in the admin view.

Use the environment variable given to us as `HELLOASSO_HOSTNAME` to
compute the hostname used for helloasso in our CSRF trusted origins.

If the environment variable indicating debug is set, the root logger is
set to "DEBUG" levels of verbosity. Otherwise, it's set to "INFO".

Refactor and document the helloasso oauth2 token retrieval class,
renaming it in the process from Tokens to Token (singular).

Otherwise the CI cannot work

This commit makes the final connection between Tournament object and
Product object by creating on save() the Products associated to the
Tournament

* Use the is_announced field
If this field is set to false, the /tournament/tournament/<id>/full
returns only the requested id. This allows the creation of tournaments
before the announcement date.

* adding is_announced in the list display

Add a `tournament` field to a Ticket that lets us know what tournament
it is linked to.

Use an ArrayField, which is Postgresql specific, to store a list of
Decimal fields that have a minimal value of 0.

Also adds tests, and is needed for #49.

Add fields to a Product and a Tournament that reflect the starting
moment at which they can be bought/you can register, and the time limit
to do so.

Also add foreign keys to a tournament to store the products it creates,
so as to not created them multiple times. These products are updated
whenever their Tournament gets changed, but not the other way back (that
will be done later).

The API also enforces time constraints, as well as whether or not a
tournament is announced.

Do not reuse the same args and kwargs used to create the first instance
of a Tournament in a second call so as to not try and re-insert the same
object with the same primary key a second time.

Translate the strings used for validation errors introduced in the
second to last commit, c357aaf.

Add a method that computes whether or not a team can be considered valid
at any given point, based on quotas of people who paid.

For now, the parameter `n` used is the number of people who joined the
team. Very soon, it will be changed by the number of slots in a team
(which is tournament dependent).

Add a Django admin action that triggers a refund of a transaction.
Consequently, add a hook to the payment callback class that performs
post-refund actions. For tournament, this post-refund hook finds any
registration paid linked to the tournament and user in question,
destroys it, and cancels associated tickets.

- Actually use the singleton object
- Implement an expiration date
- Check the expiration date when we get the token, refreshing it if need
  be
- Add timeout parameters to the request calls, and propagate/log on
  errors if need be
- Refactor some code

Transform all HelloAsso variables into constants in the settings of the
whole project.

Also adds organization slug, and normalizes variable names.

So far, it does nothing

- Fix tests (I hate timezones)
- Fix a leak of data that resulted in all tournament information being
  visible in the `event/<id>/tournaments/` dereferencement route, which
  did not take into account the `is_announced` key

- Fix ticket creation missing a mandatory key (tournament)
- Fix bug where despite buying a player ticket, you could end up
  validating a manager one
- Change fetch_registration method to determine your type of
  registration from your product, not from the fact that a registration
  is available
- Introduct the preparation hook to detect if a single registration of
  the correct type is ready to be paid before payment is initiated

Similar to Transactions, Payments cannot be deleted or manipulated, only
viewed.

Register the order_id (which is not the same as the intent id) into a
Transaction, also displaying it in the admin view

The grant_type used to retrieve an OAuth token is different whether or
not you are using client credentials (first login), or refreshing a
token (refreshes). Without this patch, initial obtention of tokens is
impossible.

Properly redirect the user… by not redirecting them. Redirects in Django
only really work within the same domain, so instead we return the URL in
a JSON reply, and will let the frontend do its magic.

At the same time, we move the call to the prepare_hook after creation of
the transaction object (for validation purposes), but before the intent
creation on HelloAsso's side. If the hooks return `False`, then
something is wrong, and we cannot proceed with payment, needing instead
to delete the Transaction.

Implement the notification channel that receives and handles two kinds
of messages:
- Order: those messages give us the layout of payments (typically here
  for us only one of them) and order number associated with our
  transaction, which we can add and update into the database
- Payment: those messages let us known the status of a payment, which
  can trigger validation or invalidation of a transaction (invalidation
  has not been tested yet, as notifications only come when a payment
  succeeds)

Properly implement refunding by iterating over defined payments for a
transaction and refunding them individually. Note that that part has not
been entirely tested yet, because our credentials do not allow us to
refund yet.

Properly handle the fact that we could get notified about a transaction
we do not know

- Remove the transaction refund admin action, mostly by commenting it
  out
- Normalize state methods, so that if you want to change the state of an
  action, you do not have to run the hooks yourself or touch the
  transaction or verify states or anything (it also logs stuff)
- Add Refunded as a supported Payment message type

We had `manager_price_onsite` in there twice.