Add Scope to PG

[anthonyra]

@jeffgrunewald @andymck thoughts?

sibyl/src/sibyl_bus.erl

Line 22 in 73ce7b3

pg:start_link().

I was poking around in Sibyl to understand how to view which gateways are connected to the durable validator better then using,

ss -an | grep 8080 | grep EST | wc -l

or similar.

I was able to hack a working list of gateways based on the sibyl code, but adding a scope will help tremendously. Only concern is that there's a note on the PG man page of Erlang.

Scope name is used to register process locally, and to name an ETS table. 
If there is another process registered under this name, or another ETS table 
exists, scope fails to start.

Local membership is not preserved if scope process exits and restarts.

Which tells me it's an ETS table and on restarts of the miner could lead to dropped client connections to the validators. However, shouldn't this already be the case?

TL;DR - Would it make sense if I did a PR to add a scope to the PG to make tracking connected hotspots easier or was there a reason it wasn't done from the get go?

Here's the hacky work around for now...

miner eval 'Topics0 = [{binary:match(M, <<"poc_notification">>), M} || M <- pg:which_groups()], Topics1 = [split_binary(M,E) || {{_,E}, M} = T <- Topics0], [ libp2p_crypto:bin_to_b58(A) || {_,A} = T <- Topics1].'

[jeffgrunewald]

If the miner restarts the client connections would indeed be dropped, so the only additional concern here would be if there were somehow a name collision that would trigger a restart that the validator otherwise wouldn't have had.

The biggest concern here I can think of would be the lack of compatibility between pg and pg2; I'm not familiar with the reasoning behind having both versions supported (OTP versions older than 23) but that feature wouldn't be available on the (ironically older) pg2

[anthonyra]

It does appear that scope isn't an option for the older pg2 ... now it's not a game changer based on how the topics are generated but it would have been an easier "filter"