de-MSC-ifying space summaries (MSC2946)

[swedgwood]

This PR moves and refactors the code for MSC2946 ('Space Summaries') to integrate it into the rest of the codebase.

Solves #3096

Pull Request Checklist

• I have added Go unit tests or Complement integration tests for this PR or I have justified why this PR doesn't need tests
• Pull request includes a sign off below using a legally identifiable name or I have already signed off privately

Signed-off-by: Sam Wedgwood [email protected]

[devonh]

Overall things are looking really good and in the right place!

[swedgwood]

(rebase on main)

[swedgwood]

I've opened this PR up to review now, but just a few things to note:

• I'm looking at adding tests for this PR to complement, so I haven't fully tested these changes yet (EDIT: the tests already exist, and they're failling, so going to fix that as well) Complement is now passing
• Because I added room hierarchy querying to the Queryer struct in the roomserver API, and room hierarchy querying may require requests over federation, I moved around the initialisation order, such that Queryer is initialised when SetFederationAPI is called (and gives Queryer a handle to the federation API). However, as creating a new user API with userapi.NewInternalAPI depends on some methods implemented by Queryer, this meant I had to move around some lines of code to make this work. Though, in most of the tests, there is no fsAPI to set, so I added a lot of rsAPI.SetFederationAPI(nil, nil) to make this work. This feels like a bit of a hack, but not sure how else to do it. Do give me your thoughts when reviewing :)
• I also need to update some names in GMSL, to remove mentions of MSC2946 from some identifiers. However I'm not sure how I should do this without breaking existing versions of dendrite.
• Also, I've mostly opted for the term 'room hierarchy' instead of 'space summary' to reflect the URL route, but if you think 'space hierarchy' or 'space summary' or some other term would be better, let me know

[codecov]

Codecov Report

Patch coverage: 3.83% and project coverage change: -0.73 ⚠️

Comparison is base (297479e) 65.28% compared to head (31f86e6) 64.55%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3134      +/-   ##
==========================================
- Coverage   65.28%   64.55%   -0.73%     
==========================================
  Files         504      506       +2     
  Lines       56389    56992     +603     
==========================================
- Hits        36814    36794      -20     
- Misses      15770    16390     +620     
- Partials     3805     3808       +3     

Flag	Coverage Δ
unittests	49.17% <3.83%> (-0.54%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
cmd/dendrite/main.go	61.42% <ø> (-0.81%)	⬇️
federationapi/api/api.go	100.00% <ø> (ø)
federationapi/internal/federationclient.go	53.33% <0.00%> (-0.75%)	⬇️
federationapi/routing/query.go	19.51% <0.00%> (-14.30%)	⬇️
internal/caching/cache_roomservernids.go	71.42% <ø> (ø)
internal/caching/cache_space_rooms.go	0.00% <0.00%> (-50.00%)	⬇️
roomserver/api/api.go	66.66% <0.00%> (-33.34%)	⬇️
roomserver/api/query.go	25.42% <0.00%> (-7.91%)	⬇️
roomserver/internal/query/query.go	58.22% <ø> (ø)
roomserver/internal/query/query_room_hierarchy.go	0.00% <0.00%> (ø)
... and 10 more

... and 21 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[devonh]

Do we need this type? NewDeviceNotServerName never seems to be used, we only use the servername variant. In which case the code that uses this should just take a spec.ServerName.
Or am I overlooking a use case somewhere? I'd prefer not to have a type like this.

[swedgwood]

I made this type because room hierarchy querying has slightly different authorisation logic depending on whether you call it from the client API or the server API. NewDeviceNotServerName is used in the client api clientapi/routing/room_hierarchy.go. Annoyingly Go doesn't have any concept of sum types so I improvised a bit