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

The crash looked something like:

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
[...]
    raise TypeError('computer_id and partition_id or request_dict are '
TypeError: in constructor for ComputerPartition: computer_id and partition_id or request_dict are required

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.

This fix is mostly cosmetic: as soon as the frontend is ready, the client parses the forwarded answer correctly, so this was only a transient bug. And only when a proxy that forwards requests is involved, so essentially only in Theia. But it will make tutorials look nicer :)

Also fix ComputerPartition.__getinitargs__ to fix serialisation of "unready" ComputerPartition objects into xml for transfer to the client. It was the specific cause of the TypeError in the original crash but fixing it did not prevent the client crashing in other ways just after. Note that the only time a ComputerPartition is serialised to xml is when the proxy forwards a request; usually a SoftwareInstance object is serialised/sent instead and then converted to ComputerPartition in the client. Now that the proxy sends 408 for unready allocations, the fix to ComputerPartition.__getinitargs__ has no effect, but I kept it anyway.