leaking sockets II ?

Nobody has claimed this yet.

The metaclass abstraction is leaking sockets, I think.
The mwe is hard to make (but nonetheless attached), but it's simple to visualise that the side effect of init, via the side effects of a possibly confusingly named set_persistent (which will connect a socket by default) result in a open socket, that will never be destroyed (until the interactive session is over (or gc zaps) 👀).

```python
"""
bug tester
"""
import logging
import socket

logging.basicConfig(level="DEBUG")
log = logging.getLogger(__name__)

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(("", 9997))
server.listen(5)

BUFFER_SIZE = 1400
DEAD = 1

def receive(sock, eof: bytes):
chunks = []
recv_more = True
bytes_recd = 0
while recv_more:
chunk = sock.recv(BUFFER_SIZE)
log.debug("got %s", chunk)
if chunk == b'':
logging.info("socket closed")
return 0, DEAD
chunks.append(chunk)
bytes_recd = bytes_recd + len(chunk)
if eof in chunk:
recv_more = False

log.info("recvd %d", bytes_recd)
return bytes_recd, b''.join(chunks)

while True:
log.info("start one recv")
try:
(client, adresss) = server.accept()
except KeyboardInterrupt:
server.close()
break

log.info("client %s", client)

while True:
try:
bytes, msg = receive(client, b"\n")
if bytes == 0 and msg == DEAD:
client.close()
break
client.send(msg)
except KeyboardInterrupt:
log.info("Closing")
break
```

Now create two instruments withe the same name: and watch how many connections appear.
Eventually they may die and get GC, but does seem dangerous.
Possibly also related to #411 .

@alexcjohnson

Start by reproducing the attached Python example while creating two instruments with the same name, then trace metaclass initialization and the set_persistent path described in the issue. Compare the behavior with the concern in #411; the issue is done when repeated instrument creation no longer leaves unintended sockets open and the lifecycle behavior is covered by a regression check.

Written by the indexing model from the issue text.