Panic on ChildAccount.getCapability() adds query complexity

[sisyphusSmiling]

Shared from @leontastic in Discord:

I'm running into a hard-to-debug error that is also hard to recover from.

On line 20 there is a call to addr.forEachPrivate to get private paths on the account
On line 25 we call childAcct.getCapability with those paths

Then we run into this error requested capability is not allowed https://github.com/onflow/hybrid-> custody/blob/main/contracts/HybridCustody.cdc#L595

A few issues here:

1. Obviously childAcct.getCapability is accessing a disallowed capability. But why does it panic? Could it not return a nil value instead?
2. Why does this script use addr.forEachPrivate if some of these paths may result in a panic? Should the list of paths to capabilities be derived from the published CapabilityFilter instead?
3. Assuming this is the only way to enumerate and find child capabilities, and that there is no way to guarantee that all private paths of the parent are also available on the child, how can the error be prevented? Ideally this script would just skip over any missing capabilities.

[sisyphusSmiling]

My thoughts here are:

1. I don't see why we couldn't return nil on getCapability(). In fact, it would better match expectations given the function signature.
2. We have to iterate over private paths bc there is no other source of truth. Filters store allowed/disallowed types, not paths
3. I think the best path forward is to update the contract to return nil instead of panicking.

This wouldn't require changes to method signatures, but a logic update within ChildAccount.getCapability(path: CapabilityPath, type: Type): Capability? after the filter check on the retrieved Capability type here.

[sisyphusSmiling]

Changes from #160 have been deployed to Testnet & Mainnet in the following transactions:

Testnet: a7fadbd22f768a777aefc9c29e7dad546a4c5c90fac72170a5e3a53ff1f7734d
Mainnet: 3a9363154c64a4ac1c6609ac31adaef62b6fa71844b596ddbc9d62fc97d2bb51