treaty: subscribe for treaties to prevent race condition

[pkova]

When you search for a ship for the first time in the landscape software distribution UI it's very common to enter a scenario where the UI gets stuck on "X apps found, waiting for entries", yet the entries never show up until you refresh the page. Whether you hit this case seems to be dependent on how fast the %vitals connection check completes.

This PR fixes the issue by having the frontend subscribe to the treaty instead of scrying for it. This requires a new /treaties/ship subscription endpoint which is also implemented here.

[pkova]

What is a sovereign treaty? Do I need to somehow give a /treaties/ship fact here also?

landscape/desk/app/treaty.hoon

Lines 344 to 353 in 77c1cc8

	++ give
	:: notably gives on the /treaties path, like +give:tr does.
	:: this should not give duplicate facts, because sovereign treaties
	:: are handled in this core, not as "normal"/foreign treaties.
	::
	^- (list card)
	=/ t=treaty (~(got by sovereign) desk)
	:~ (fact:io (treaty-update:cg %add t) /treaties ~)
	(fact:io (treaty:cg t) path ~)
	==

[Fang-]

What is a sovereign treaty? Do I need to somehow give a /treaties/ship fact here also?

A "sovereign treaty" is one we are publishing ourselves. These are stored separately, in the sovereign map.

Since the new /treaty/[ship] subscription endpoint you added (in +on-watch) doesn't currently give initial results from the sovereign map, it would be wrong to give facts for any changes there.

But, arguably, we should pull results from sovereign in addition to treaties.

...The scry endpoint doesn't account for that though, and in the common case it probably doesn't matter?

[Fang-]

This is the case for the scry too, but I'm kind of surprised this isn't doing a (~(put in alliance) ship), to make sure the ship we're actually explicitly asking about is also in there, always.

[bacwyls]

#250

[pkova]

I found a problematic case on ~wolref-podlex. He was failing to see almost any desks in the software distribution UI when searching for a ship even with my previous fix applied. When investigating his %treaty state I noticed that everything seemed to be in order except that for some distribution ships the allies map contained the ship in the key but the value was unexpectedly empty.

This is very likely caused by this piece of code:

landscape/desk/app/treaty.hoon

Lines 61 to 64 in 9e8258e

	?- -.update
	%add [~[watch:al] this(allies (~(put by allies) ship *alliance))]
	%del [~[leave:al] this(allies (~(del by allies) ship))]
	==

Sometimes the frontend adds an ally with the %add case there. If we have already subscribed to the ally watch:al no-ops in gall but we still bunt the alliance! This problem is fixed by unsubscribing first.

It is unclear how many ships are affected by this issue. To make sure everybody has their %treaty working I wrote a migration where we resubscribe for every ship with a bunted alliance.

[Fang-]

I think the approach here might be preferable to #269 because it gives you a way to "full refresh" for any given ally. The frontend probably shouldn't be doing that willy-nilly though.

Either way, as written this should be a straight improvement on existing behavior, so I'd be happy with merging it. We can always continue tweaking later.