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

### 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.