multi: refactors for bison wallet integration

[buck54321]

A handful of refactors to make mesh work for Bison Wallet. .

1. Clients can subscribe to multiple topics at once
2. Topics are now hierearchical/namespaced. Critically for Bison Wallet, this allows the client to get a list of existing markets, but opens up the possibility for more targeted information feeds that would keep the excess chatter to a minimum.
3. Tests are refactored to use requireEventually throughout instead of time.Sleep. This reduces the runtime of the tests from > 30 s to < 4 s on my machine.

I tried to keep stylistic changes to a minimum, but there are a couple. I also recognize that there might be some conflicts with some existing PRs, so I apologize for that and am happy to take on the brunt of the rebasing work it might generate.

[martonp]

Some suggestions for the trie: 07327c1

[martonp]

Should we allow users to be able to subscribe to a higher level topic i.e. "markets" and then receive updates for all subtopics? Currently, bison wallet will have to keep searching for markets and subscribe to any ones they are not subscribed to in order to get updates.

Also, the current technique to search if topics exist or not depends on whether or not any clients have subscribed to the topic on the node that is being queried. I think it should instead depend on whether on not any data has been broadcast on that topic in the past X amount of time.

[buck54321]

Should we allow users to be able to subscribe to a higher level topic i.e. "markets" and then receive updates for all subtopics? Currently, bison wallet will have to keep searching for markets and subscribe to any ones they are not subscribed to in order to get updates.

I guess I assumed that there would be some kind of notification when a new topic is created.

Also, the current technique to search if topics exist or not depends on whether or not any clients have subscribed to the topic on the node that is being queried. I think it should instead depend on whether on not any data has been broadcast on that topic in the past X amount of time.

Hmm, yeah. Nodes will have to somehow synchronize their subtries? Solution needed.

[martonp]

I guess I assumed that there would be some kind of notification when a new topic is created.

If we allow subscribing to "markets" and that causes the user to be subscribed to all sub-topics, they will be notified whenever a message is sent on any market-related topic.

Hmm, yeah. Nodes will have to somehow synchronize their subtries? Solution needed.

If searching for topic is not based on subscriptions, but rather based on whether or not a topic has been active in the past X minutes, then it will be easier, as all nodes receive all broadcast messages. I'm also thinking we should cache messages in tatanka nodes for a certain amount of time, so that when new users subscribe to a topic, they will immediately receive the most recent data.

[buck54321]

Should be ready for review again. Please don't get too hung up around the nuance of subscribe/unsubscribe error handling. I want to work it out in conjunction with some Bison Wallet work to see how it will work best with the caller's needs.

[dnldd]

Removing expired bonds is now a subset of adding bonds. It's not explicit and couples the two processes. I think we should retain ClearExpiredBonds.

[buck54321]

It was already couples to AddBonds, just requiring an additional action by the caller.

Then it was also done every BondStrength was called, which would be a no-op virtually every call.

[dnldd]

My bad, thought there was a separate process removing expired bonds. Disregard.

[dnldd]

Looks good