Rework /internal/queue package

[dcantah]

Given our use cases for this package, we don't need methods that don't block
on reads if there's no value to be read. Due to this, I've removed the
ReadOrWait function and did a small redesign of the methods to be more
in line with standard queue method naming.

• Change Read/Write/IsEmpty to Dequeue/Enqueue/Size and remove ReadOrWait.
  Now there is no version of Read/Dequeue that doesn't block if the queue
  is empty.
• Fix up tests to be in line with this removal of the non-blocking read
  and simplified most of the tests.

[helsaawy]

A couple of thoughts:

1. Would a DequeueNoWait() be useful at all?
2. I kind of like the RWMutex, for a couple reasons:
   a. if we add a Peek() (any, error), then it a RLock would make sense
   b. if we use the RLock at the beginning of De/Enqueue to check if the queue is closed/empty, then multiple attempts to read/write can fail simultaneously instead of each waiting in turn, so a moderate optimization (though I doubt performance is currently a concern)
3. since MessageQueue shouldnt be copied (cause of closed bool), there a gross hack that sync uses to raise go vet errors that we may want to use here

[dcantah]

A couple of thoughts:

1. Would a DequeueNoWait() be useful at all?
2. I kind of like the RWMutex, for a couple reasons:
   a. if we add a Peek() (any, error), then it a RLock would make sense
   b. if we use the RLock at the beginning of De/Enqueue to check if the queue is closed/empty, then multiple attempts to read/write can fail simultaneously instead of each waiting in turn, so a moderate optimization (though I doubt performance is currently a concern)
3. since MessageQueue shouldnt be copied (cause of closed bool), there a gross hack that sync uses to raise go vet errors that we may want to use here

1. I removed it as for our purposes at the moment we'd always want to block, but if we find future use cases where it may come in handy we could add it back in
2. We couldn't read lock for Dequeue right? We could up until the close check but after we'd just need to lock for the actual modify on the queue. Although agree if we could get away with rlock it'd be nice. rlock for peek makes sense, but I'm not sure we have a use for it here; it would also help for Size(), but we don't even use Size() in this codebase 🤣
3. Oh my word...

[dcantah]

@helsaawy I just stuck with rwmutex as we can use it for Size check at least