[RSD] Deleting a machine directly still leaves it composed in the pod

per @roaksoax request I check if deleting the pod *without* deleting the machines makes them actually decompose - the answer is, no

I am not seeing what Brendan is mentioning in #1. I see this:

root@maas-dev:~# curl -s -k -u admin:admin -X GET https://10.3.0.1:8443/redfish/v1/Nodes
{
  "@odata.context" : "/redfish/v1/$metadata#Nodes",
  "@odata.id" : "/redfish/v1/Nodes",
  "@odata.type" : "#ComposedNodeCollection.ComposedNodeCollection",
  "Name" : "Composed Nodes Collection",
  "<email address hidden>" : 4,
  "Members" : [ {
    "@odata.id" : "/redfish/v1/Nodes/226"
  }, {
    "@odata.id" : "/redfish/v1/Nodes/255"
  }, {
    "@odata.id" : "/redfish/v1/Nodes/256"
  }, {
    "@odata.id" : "/redfish/v1/Nodes/257"
  } ],
  "Actions" : {
    "#ComposedNodeCollection.Allocate" : {
      "target" : "/redfish/v1/Nodes/Actions/Allocate"
    }
  }
root@maas-dev:~# maas admin pods create type="rsd" power_address="10.3.0.1:8443" power_user="admin" power_pass="admin"
Success.
Machine-readable output follows:
{
    "architectures": [
        "amd64/generic"
    ],
    "used": {
        "local_disks": 4,
        "memory": 124992,
        "cores": 176,
        "local_storage": 479999999996
    },
    "total": {
        "local_disks": 7,
        "memory": 249984,
        "cores": 352,
        "local_storage": 959999999999
    },
    "name": "loving-bison",
    "type": "rsd",
    "resource_uri": "/MAAS/api/2.0/pods/190/",
    "available": {
        "local_disks": 3,
        "memory": 124992,
        "local_storage": 480000000003,
        "cores": 176
    },
    "id": 190,
    "capabilities": [
        "composable",
        "fixed_local_storage"
    ]
}
root@maas-dev:~# maas admin pods read
Success.
Machine-readable output follows:
[
    {
        "total": {
            "local_storage": 959999999999,
            "cores": 352,
            "memory": 249984,
            "local_disks": 7
        },
        "available": {
            "cores": 176,
            "local_disks": 3,
            "memory": 124992,
            "local_storage": 480000000003
        },
        "id": 190,
        "architectures": [
            "amd64/generic"
        ],
        "name": "loving-bison",
        "type": "rsd",
        "capabilities": [
            "composable",
            "fixed_local_storage"
        ],
        "used": {
            "local_storage": 479999999996,
            "cores": 176,
            "memory": 124992,
            "local_disks": 4
        },
        "resource_uri": "/MAAS/api/2.0/pods/190/"
    }
]
root@maas-dev:~# for i in {1..4}; do maas admin pod compose 190; done
Success.
Machine-readable output follows:
{
    "system_id": "spfkee",
    "resource_uri": "/MAAS/api/2.0/machines/spfkee/"
}
Success.
Machine-readable output follows:
{
    "system_id": "mftwep",
    "resource_uri": "/MAAS/api/2.0/machines/mftwep/"
}
Success.
Machine-readable output follows:
{
    "resource_uri": "/MAAS/api/2.0/machines/dgx734/",
    "system_id": "dgx734"
}
Success.
Machine-readable output follows:
{
    "system_id": "7ygnk7",
    "resource_uri": "/MAAS/api/2.0/machines/7ygnk7/"
}
root@maas-dev:~# curl -s -k -u admin:admin -X GET https://10.3.0.1:8443/redfish/v1/Nodes
{
  "@odata.context" : "/redfish/v1/$metadata#Nodes",
  "@odata.id" : "/redfish/v1/Nodes",
  "@odata.type" : "#ComposedNodeCollection.ComposedNode...

Marking as invalid because this was not a clean testing environment. The signal registration in maasserver.models.signals.nodes was commented out from previous testing purposes. Once this was reverted and the regiond service was restarted, this was no longer an issue.

This is not a bug but a new bug surfaced once this was tested with a clean testing environment. Please see bug #1667754 for details on the new bug.