Because we want to trigger an upgrade that will remove old tables.

Note that re-dumping database_dump_version_current fixed the column
order in software table - the dump was incorrect (this also change
output of `proxy show` for this test)

Create a test for each previous versions to current version (starting
from version 10, earlier versions are not really supported).

Procedure to add test for new version can be:
 * update table structure and increase version in slapos/proxy/schema.sql
 * use generate_dump.sh script to generate
   slapos/tests/test_slapproxy/database_dump_version_$NEW_VERSION.sql
   from slapos/tests/test_slapproxy/database_dump_version_$PREVIOUS_VERSION.sql
   (with computer_id "computer")
 * add TestMigrateVersion$(NEW_VERSION)ToLatest in
   slapos/tests/test_slapproxy/__init__.py
 * use generate_dump.sh script to update in-place
   slapos/tests/test_slapproxy/database_dump_version_current.sql
   (with computer_id "slaprunner")

Instead of keeping old tables which cause confusion for humans and tools
directly operating on the database, remove old tables and create a
separate backup file.

This test was probably asserting that initial state was OK

If they are not, it mess up the simulation.

This is only for when subscription request is present, as consumption is normally irrelevant from accounting point of view.

This preserves the previous approach from non-subscriptions hosting subscriptions.

I'm now displaying the upgrade decision message as HTML. @rafael  I'm not sure if I should do the same in `rjs_gadget_erp5_page_slap_ticket_view_js.js` and `rjs_gadget_erp5_page_slap_regularisation_request_view_js.js`

/cc @alain.takoudjou

/reviewed-on nexedi/slapos.core!103

if we have host2 inside host1 inside host0 then routing from host0 to host2 needs to specify 'via' address because the destination address (of host2) is not directly seen through slaptap of host0 (because it goes only to host1).

this commit introduces a new constraint: users must now put the IPv6 address `network::1` on their ethernet interface inside the VM.

/cc @jm @rafael @alain.takoudjou

/reviewed-on nexedi/slapos.core!102

Once a user pays for a reservation, the ERP5 can generate a deduction (complete or partial). The code here, includes the needed simulation code for expand and merge the Deduction into the invoice.

Use cache to  save some promise instance information.
First run of slapgrid fill each promise cached (when there is no cache). The next run will check some usefull info like if promise `is test less` or promise `is anomaly less` directly from cache without need to import the module.

Cache is updated if promise file or module change, or if the promise periodicity expire (when the promise it update cache).

/reviewed-on !101

- Round tax comparation, else we hit floating point impression.
- Free trial user is defined by ERP5 Login reference and not Person Reference.

Simple subscription Case
Request three instances (ie.: 3 VMs) Case
Two concurrent Subscriptions Case

If the first 3 months are payed, the subscription request is confirmed (allowing allocation).

When causality is set and it is a Subscription Request, do not aggregate services (it will generate individual inviduals invoices per Subscription).

When a user has multiple requests, it should not merge, and it should generate 1 invoice per subscription request.

slapos_accounting: Use specific trade condition if Hosting Subscription comes from a Subscription Request

This allow the system differ the 2 scenarios.