See merge request nexedi/slapos.core!490

This was introduced in 081e745e and I don't see how it could have been
useful.

See merge request nexedi/slapos.core!494

    It was used on OrderBuilder_generateUnrelatedInvoiceList but the code dont relies on it anymore.

See merge request nexedi/slapos.core!492

An error slipped in 92da569e (slapos_jio: Drop Handlebars, 2022-06-08)

    The forms were removed long ago, and those actions werent removed

When forwarding a request to an external master, e.g. frontend request,
the master might first answer with status code 408 to indicate the
requested resource is not ready.

The slap library wraps the answer into a ComputerPartition object, even
when the master sends 408: in that case the object only contains the
parameters of the original request.

Until now, when the external master answered 408, the proxy simply
forwarded the ComputerPartition object returned by the slap library
with code 200, instead of forwarding code 408.

This played against the assumptions of the slap library in the client
on the receiving end, resulting in a crash. This was the case even when
using `requestoptional` recipe in buildout.

Now the proxy detects when the object returned by the slap library is
actually the result of a 408 answer, and aborts with code 408.

See merge request nexedi/slapos.core!488

  Most liketly a copy and paste mistake

    Whenever you define a slave, the option_index inst the software-type but the property of the dict/object.

See merge request nexedi/slapos.core!487

  This category is used whenever the user wants disallow allocation for the time been. It do not intend to re-open again after a procedure or do not intend to terminate the machine, just dont want anything be allocated on it.

See merge request nexedi/slapos.core!486

   category close and not closed, and do not auto cancel upgrades for computers for termination.

   This should be handled by setting never on upgrade scope.

   Those actions were dropped from ancient site and forgotten to be removed.

   Only Monitor Scope should be taken into account.

   Whenever allocation scope changes, the capacity is close, and the proper alarm will re-open it later a moment after. This prevents when you change from close to open, to get a miss-updated window, and something is allocated before it capacity is calculated.

     Do not touch on monitor scope, except when it is None or allocation is "Close Forever", this allow the user to keep monitoring closed computers (Maintenance, termination...), since ONLY allocation is closed, and the computer is supposed to work normally with whatever is inside.

  ... to decide which computers to select for check for upgrades

It's very useful in some deployments to control maximum time of
partition processing. This parmater can end up in slapos.cfg configuration
file or command line.

See merge request nexedi/slapos.core!480

See merge request nexedi/slapos.core!485

  ... to make publication_url happy