See merge request nexedi/slapos.core!434

Until now, the broadcast address was used for the tun interface instead
of the first address of the range.

See merge request !436

See merge request nexedi/slapos.core!435

  We do want to ignore payments that occur after the at_date.

  We want to know if at a certain date, there still unpayed documents older them that date, if the document is payed after, (and grouped) we unconsider it.

   This was missing to remove since we dropped all mass upgrade code and relies exclusively on Upgrade Decisions.

   Upgrade decisions are also tickets (messages are issued), this makes things consistent with the other tickets (Regularisation Requests and Support Requests)

   This allows administrator see issued messages.

See merge request nexedi/slapos.core!431

If computer partition requested state is `started`, slapos node boot will start
partition services on reboot, event if the node is not able to connect to master or
has no internet.

See merge request nexedi/slapos.core!428

See merge request nexedi/slapos.core!430

   ... Unify scripts into Base_getEventList

  In order to use getMovementHistoryList too

   It is used to get the events that follow up to a ticket that aggregates (or sub object aggregates) to an document (usually Compute Node or Instance Tree).

   Reuse Base_getOpenRelatedTicketList to query tickets consistently and extends original goal to also show Upgrade Decisions.

   This tab shows all Tickets related to the computer and to all instance trees that has one instance allocated on it (even if isn't the one that is failing).

   Use default_or_child_aggregate_uid is enough (and simpler).
   Use specific states to be consistent with RSS queries.

   Reduce the number of scripts and refactor the query script to rely on getMovementHistory.

   Before only the latest event was notified, to reduce the list and only to ping the user to access the site. Now all events are considered on the list (not the latest ones) and include some general clean up on base RSS feeds.

  Now the goal is save the configuration and later assert with saved configuration on the actual site.

  This may give us other uses for this tooling, like, save before and after an upgrade (to know the actual delta) and save after an upgrade to know later the local changes done over time.

  This without loose the possibility of audit (since you can upload a file after fetch the configuration from the unit tests)

   We shouldn't keep this in git, but it should be created or handled after an upgrade by the developer.

See merge request !423

See merge request !429

   Events are creates via script (and API) now, instead jio_post.

Add `README.md` instructions explaining how to adapt the migration
tests after upgrading the proxy database version.

When migrating entries, use `INSERT OR REPLACE` to get rid of duplicate
rows that cause constraint violations, instead of raising an exception.

Note that this only affects the `forwarded_partition_request` table:
for other tables it changes nothing in terms of behavior because the
intial tables already cannot contain conflicting rows.

Insert duplicate entries in `forwarded_partition_request` table of each
database dump of previous versions, and assert that only a single entry
remains after the migration.

See merge request !427