`null` bindings from `where` currently function as "catch-all" in `delete`

[aaj3f]

Description

Because it is possible to use an optional expression in a where and then to use bindings from the optional in delete, it is therefore possible to have null values arrive into delete bindings, e.g.

"where": [
    {
      "@id": "_:f211106232533005",
      "?p": "?o"
    },
    [
      "optional",
      {
        "@id": "_:f211106232533005",
        "f:allow": {
          "@id": "?childSubj",
          "?childPred": "?childObj"
        }
      }
    ]
  ],
  "delete": [
    {
      "@id": "_:f211106232533005",
      "?p": "?o"
    },
    {
       "@id": "?childSubj",
       "?childPred": "?childObj"
    }
  ]

In the example above, we want to delete any child entities on a particular property IF THEY EXIST. If none exist, then ?childSubj, ?childPred, and ?childObj are all null, and the delete expression for that object ends up deleting every [s p o] triple in the ledger

We need

1. To ensure that null values in delete expressions stop acting like a catch-all (and instead, possibly prompt a drop of that entire sub-expression within the delete)
2. Ensure that we are able to deliver the user story described by the above, whether with optional or not, we need to be able to select for deletion any and all (possible) existing downstream nodes. Note that in the example above, we want to delete all the facts on "@id": "_:f211106232533005" regardless, and we don't want the non-existence of downstream nodes to cause the entire txn to be dropped (hence the thought to use optional

[dpetran]

I believe this can be closed, I can no longer reproduce it.