chore: cleaned up README

Author: CMCDragonkai

README.md

@@ -154,58 +154,3 @@ npm publish --access public
 git push
 git push --tags
 ```
-
----
-
-I need to be locked together.
-
-These need to be atomic operations.
-
-The only issue is that the "atomicity" is controlled outside of `QUICConnection` atm.
-
-Whereas it seems to make sense to do this directly?
-
-```
-recieve
-[IF IS DRAINING IS TRUE SKIP SEND]
-send
-[CLOSE] - we may be "closed here"
-set-timeout
-```
-
-This would be triggered by:
-* QUICStream
-* keepAliveTimer
-* after onTimeout
-
-```
-send
-[CLOSE] - we may be "closed here"
-set-timeout
-```
-
-Remember you may also "receive" and end up closing too. But you will always check if you need to send first before checking the close. At worst it will tell you it's done.
-
-Now of course we enable calling recv and send.
-
-But `send` actually ends up calling multiple things here.
-
-But if `recv` is synchronous, you can always call it infront of `send`.
-
-This technically means `send` should be encapsulating the logic of setting the timeout.
-
-If you want to make sure it's re-entrant, you can just "lock" on the send call.
-
-The setTimeout is then protected.
-
-The `recv` call is made synchronously.
-
-
-
-Receive Send Timer, Send Timer (all of this requires locking the conn lock)
-
-Closing too, it should require the conn lock
-Receive Send [Close] Timer, Send [Close] Timer
-It's all optional
-It's the send that has to do Send, Close, Timer... that's what needs to check it all
-Forget about events for now