`firebase_admin.db.reference` leaks connections in a `CLOSE_WAIT` state

Start by reproducing the issue with a Python websocket server, creating a firebase_admin.db.reference and calling set in the connection handler. Use netstat after connections terminate to inspect CLOSE_WAIT sockets. Done means the reference connection lifecycle is explained and the reported accumulation is resolved or the required teardown behavior is documented.

Step 2: Describe your environment

• Operating System version: OS X Ventura 13.4
• Firebase SDK version: 6.2.0
• Firebase Product: database
• Python version: 3.11.2
• Pip version: 23.1.2

Step 3: Describe the problem

I have a Python websocket application that creates a reference to RTDB via firebase_admin.db.reference, and writes to it via the set method. I create one reference per connection to my database. It appears that this reference does not necessarily get cleaned up, as I've noticed in my server that connections with a CLOSE_WAIT state are aggregating specifically with this RTDB update. More concerning is that the application appears to be receiving bytes of data at a consistent rate from this connection despite it being in a CLOSE_WAIT state.

What is the proper way to tear down a reference once I know I'm done with it? It seems like this is a bug from the firebase_admin python package as there don't be any instructions or indication that we need to tear down the reference.

Steps to reproduce:

1. Create a Python websocket server with the websockets library
2. Within the connection handler, instantiate a reference via firebase_admin.db.reference and write a value
3. Approximately 1 minute after the connection terminates, use netstat to observe that the connection still exists in a CLOSE_WAIT state and that the application is receiving data from it.

Here's my netstat output

root@474683837e04:/app# netstat -ntuap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.11:38913        0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1/python
tcp       25      0 172.24.0.3:34160        34.120.160.131:443      CLOSE_WAIT  1/python
tcp        1      0 172.24.0.3:58576        142.250.191.74:443      CLOSE_WAIT  1/python
tcp6       0      0 :::8080                 :::*                    LISTEN      1/python
udp        0      0 127.0.0.11:54888        0.0.0.0:*                           -

Using connections with all of the reference related code commented out and then netstat'ing after shows that this issue does not appeare.