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 !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 !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.

When the Hosting Subscription comes from a Subscription Request, the Trade Condition applied is a different one (slapos_aggregated_subscription_trade_condition).

Update all related scripts to work accordinally.

SPL on this case are started as soon they are created and a payment generated.

This is used for subscription mode, like rapid.space VM-Like services.