Fix human-readable name for ImageMetadata

[praseodym]

Changes

The Webpage Capture boefje creates images from HostnameHTTPURL OOIs,
which means that after the normalizer creates an ImageMetadata OOI
its reference points to a HostnameHTTPURL OOI instead of an HTTPResource
OOI. #1560 was created to fix this, but for
now we can fix the human-readable name by trying to parse the reference
as a HTTPResource first and HostnameHTTPURL if this fails.

This fixes the "IndexError at /en/mispoes/objects/, pop from empty list"
error.

Issue link

Fixes #1539

Proof

Please add some proof of your working change here, unless this is not required (e.g. this PR is trivial).

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified;
• This PR only contains functionality relevant to the issue; tickets have been created for newly discovered issues.
• I have written unit tests for the changes or fixes I made.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have performed a self-review of my code and refactored it to the best of my abilities.

Communication

• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have made corresponding changes to the documentation, if necessary.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[underdarknl]

As discussed, I don't think this is the solution, Not accepting HostnameHttpUrls and IPHttpUrls seems too strict too. The model might need to be more flexible, and the normalizer more flexible about the input_ooi type

[praseodym]

Changed the PR: first try to parse the reference
as a HTTPResource and HostnameHTTPURL if this fails.

[dekkers]

In the model definition the reference points to only HTTPResource. That we can save objects that reference other object types is something we should fix and I don't think we should add support in the format_reference_human_readable for buggy behaviour. If ImageMetadata should be able to reference both objects we should update the model definition.

[praseodym]

#1559 was created to fix the Webpage Capture boefje, #1560 was created to fix the normaliser that creates the ImageMetadata OOI.

As far as I know there is currently no way to have a ReferenceField with multiple possible types. If we were to build that, we'd have to at least add the referenced OOI's type name to the ImageMetadata OOI's natural key. This would break compatibility with existing data.

The only two ways we currently have to discern ImageMetadata OOIs referencing HostnameHTTPURL OOIs instead of an HTTPResource OOI is to count the number of | symbols in the natural key, or to try to tokenise it as one type and fall back to the other type if that fails. This PR implements the second option.

[Darwinkel]

Checklist for QA:

• I have checked out this branch, and successfully ran a fresh make reset.
• I confirmed that there are no unintended functional regressions in this branch:
  • I have managed to pass the onboarding flow
  • Objects and Findings are created properly
  • Tasks are created and completed properly
• I confirmed that the PR's advertised feature or hotfix works as intended.

What works:

• No apparent regressions
• IndexError is gone