fix: #236

and fix an issue where crn wouldn't get fetch on the crn list due to filter

Also include the fix from this other PR spotted by @RezaRahemtola (#236):

When deleting an instance, the behavior for the ports-forwarding aggregate is different between the CLI and the UI:

• The CLI will update the aggregate to keep the value of the item hash to the existing values (example: https://explorer.aleph.cloud/address/ETH/0x238224C744F4b90b4494516e074D2676ECfC6803/message/AGGREGATE/4acb1fac2b28a54c73160c1cdde93c51bb4712be10ca34f934b209b832b2ebbb). This may be an unwanted behavior to investigate, but it is not the scope of this tentative fix.
• The UI will update the aggregate to set the value of the item hash to null (example: https://explorer.aleph.cloud/address/ETH/0x238224C744F4b90b4494516e074D2676ECfC6803/message/AGGREGATE/6bc45c2746f289e8fcf12fd44a0b41eae4c57ba408174cfaa63dda3ca002e2bb)

The problem is that the types in the SDK (and thus in the CLI) don't expect an item hash in the ports-forwarding aggregate to be null (as you can see, I just added the possibility in this PR).

This means that if a user deletes an instance in the UI, then the CLI won't function properly anymore, as it will throw Pydantic parsing errors when fetching the ports, for example when deleting an instance:

Unfortunately the fix is probably not as simple as adding this line:

• Adding the possibility of null ports may (well is according to the tests) break some stuff in the SDK / CLI so it should be done carefully
• Updating the UI to avoid setting null values is also out of the question imo, as it won't solve the issue for existing users (and after a quick look at the UI, it's using a generic part of the code to delete the ports so it would need a bit more than a single line change too)