Update blockprotocol + mock-block-dock. Remove destinationEntityVersionId

[CiaranMn]

🌟 What is the purpose of this PR?

Upgrades the versions we are using of the blockprotocol and mock-block-dock packages, mainly to eliminate the patching we were doing related to linkedAggregations, following blockprotocol/blockprotocol#302

Since the latest blockprotocol removes provision for destinationEntityVersionId, I have also removed our support for it (that we weren't using) from HASH.

As part of this I actually made a few more changes to bp types locally, to split out the Filter related types further. I am going to defer reflecting these changes back into BP and then updating here again, as it can wait.

🔗 Related links

• Asana task (internal)

[benwerner01]

Thanks Ciaran, I think one minor addition to the migration scripts should be made before merging for consistency, but apart from that these changes look good to me 👍

[benwerner01]

Just curious, why do these filters each have ids in the table block? Just for the purpose of using them in the react key?

[CiaranMn]

I'm not sure - @teenoh ?

[teenoh]

we need the ids to locate a particular filter from the list of filters and update it's value when there's a change @benwerner01

https://github.com/hashintel/hash/blob/main/packages/blocks/table/src/components/filter-detail.tsx#L177-L179

[benwerner01]

Thanks Ciaran 👍

[thehabbos007]

Just adding some things i noticed outside the changes (might be more)
There's a DB error type (which isn't used?) that refers to linked entities being pinned by entityVersionId

hash/packages/hash/api/src/db/errors.ts

Line 80 in db90afc

invalid: { entityId: string; entityVersionId?: string }[];

[thehabbos007]

The changes to implied history means that the comment here is not true anymore

hash/packages/hash/api/src/db/postgres/history.ts

Lines 75 to 79 in db90afc

	Entities may also make "fixed" links to specific versions of other entities. The procedure
	for deriving the implied history in these circumstances is similar to that outlined in
	the example above, except that when a fixed link is encountered, the checkpoint is
	immediately moved to the linked version, and it's not changed unless a subsequent version
	of the reference entity updates the link.

And I assume we can remove the conditional parts here that deal with fixed VersionIds

hash/packages/hash/api/src/db/postgres/history.ts

Lines 238 to 255 in db90afc

	// made on entityId), choose the checkpointed version; or if it's a fixed link,
	// choose the specified version.
	for (const link of refLinks) {
	const linkedVersions = entityVersions.get(link.entityId)!;
	const linkedVersion = link.entityVersionId
	? linkedVersions.find(
	(ver) => ver.entityVersionId === link.entityVersionId,
	)!
	: linkedVersions[checkpoints.get(ref.entityId, link.entityId)]!;
	// If the link is fixed, and the position of the specified version in its timeline
	// is after the checkpointed version of this entity, then we need to update the
	// checkpoint.
	if (link.entityVersionId) {
	const pos = timelinePos.get(link.entityVersionId)!;
	if (pos >= checkpoints.get(ref.entityId, link.entityId)) {
	checkpoints.set(ref.entityId, link.entityId, pos);
	}

I think this change might be best to do in a separate PR, though.

[CiaranMn]

Thanks @thehabbos007 – removed the unused error and updated comments in dcd8d4e

[lgtm-com]

This pull request introduces 1 alert when merging c44707c into 4b72242 - view on LGTM.com

new alerts:

• 1 for Unused variable, import, function or class

[thehabbos007]

Thanks Ciaran! Looks good to me :)