pos-switch with reactivity and testing presence of forward and backward links

[jg10-mastodon-social]

Closes #183

• Add Thing.observeTypes
• Tests whether forward link specified by if-property or backward-link specified by if-rev are present
• Add Thing.observeRelations
• Add Thing.observeReverseRelations

Definition of Done

• Tests have been written
  • all new code is covered by unit tests
  • the happy path of a new feature is covered by an end-to-end test
    • integration test
  • manual explorative tests have been performed
• all dependencies are updated to the latest patch version at minimum
• the CI pipeline passes
• documentation is up-to-date
  • TSDoc style comments on important functions, properties and events
  • stories for new PodOS elements have been added to storybook
  • Readme.md files of PodOS elements have been re-generated
  • N/A architectural decisions are documented as an ADR
  • Changelogs are updated according to Keep a Changelog

[jg10-mastodon-social]

@angelo-v - thanks for the review. Let me know if you consider the issues to be resolved - hopefully the tests will now be easier to assess.

Note that additional fixes were made to Thing.relations, Thing.reverseRelations, accumulateValues and accumulateSubjects.
I wanted to add a test that Thing.observeReverseRelations does not push new values if relations haven't changed
The only way this can occur when a statement is added or removed with a given object is if the statement already exists with a different graph.
However, the existing Thing.reverseRelations actually included duplicate uris. I considered this to be a bug and have fixed accordingly. It turns out Thing.relations had the same issue.

[angelo-v]

question: why do we use debounce here but not on observeTypes?

[jg10-mastodon-social]

My reasoning is still developing, so would be good to discuss and see if there's a better solution:

1. I consider debounceTime to be a potentially buggy heuristic. What we want to know is that there will not be in any more emissions that would cause a rerender. I've set the time rather conservatively at 250ms. This is probably too long because it's latency that a user might notice, but on a slow device the user impact of rerendering could be worse. I expect we'll want to reduce the time but would want some evidence to support the selection of a new value.
2. So my preference was to avoid debounceTime if an argument can be made to do so. Relations are the work horse of RDF, so we expect them to change frequently and for groups to be updated at once when documents are loaded. They're also used frequently across the user interface so potentially have a big effect on rerendering (my early experiments had some very painful churn). Types are updated infrequently and are used less frequently in the user interface. I expect the first set of types to be already loaded in the store when first called, so emissions are likely to be one at a time when changes are made. It therefore felt safe to avoid the debounceTime.

I think eventually we'll need e2e tests with performance metrics and that'll provide some evidence to improve this, but in the mean time any anecdotal feedback would be good too.
We can maybe open an issue related to rerendering performance?

[angelo-v]

Thanks, sounds reasonable for now, but I am in favor of opening an issue to document that beyond this comment.

[angelo-v]

I did a rebase and some minor improvements. Looks good for me. Despite the question about the debounce I will merge this, if it turns out we will need to add a debounce there we can do it on main or a new branch