Reduce the number of subscriptions we do with relays

[afilini]

Relays limit the number of filter we can subscribe to (I think the default for strfry is 500).

We currently subscribe a lot, especially on the service side. Every conversation adds a new subscription usually. Over time this causes relays to reject our new subscriptions.

There's already a partial fix in place, which is this:

lib/src/router/mod.rs

Lines 361 to 380 in b4a163c

	// Check if there are other potential conversations to dispatch to
	for (id, filter) in self.filters.read().await.iter() {
	if id == subscription_id.as_str() {
	continue;
	}
	match self.conversations.lock().await.get(id) {
	Some(conv) if conv.is_expired() => {
	to_cleanup.push(id.clone());
	continue;
	}
	_ => {}
	}
	if let LocalEvent::Message(event) = &event {
	if filter.match_event(&event) {
	other_conversations.push(id.clone());
	}
	}
	}

When we receive an event we check if other conversations are also interested in it and if so we send it to them as well.

I think we need to come up with a smarter way of subscribing, for example we can merge subscriptions:

1. A user tries to authenticate, we subscribe to KIND == X, AUTHOR == PK1
2. When a second user tries to authenticate we un-subscribe from the first and subscibe to KIND == X, AUTHOR == (PK1 OR PK2)

We should also keep in mind that there's a maximum length limit for filters, so we have to be careful to aggregate but not too much.

[afilini]

I think it would already be a big help if we only had one main subscription for the key handshake message (kind 27010), because otherwise every time the user refreshed the login page we generate a new conversation listening for that kind and they tend to add up.

Also I noticed I introduced a regression in #34 in which I accidentally removed the expiration for KeyHandshakeReceiverConversation, so the conversations would never be removed and thus we would never unsubscribe. I have fixed it now in ed502f6