[9.x] Add unique locking to broadcast events

[DougSisk]

Queueing broadcast events is incredibly important, especially at scale. Unfortunately at the moment there is no out-of-the-box method to prevent queues from being overloaded with repeated events. This can lead to redundant broadcast events that eat up data allowances.

I'm proposing a new Illuminate\Contracts\Broadcasting\ShouldBeUnique contract that tells the dispatcher to use a separate UniqueBroadcastEvent class. If no uniqueId method or property is defined, the event's class name is used as the identifier. You can also set uniqueFor and uniqueVia like other unique queue jobs via a property or method.

[daannet]

In the test case the lock is successfully acquired after queueing the event, which shouldn't be possible if the lock was acquired. Looks like this isn't a complete solution yet.

[driesvints]

@DougSisk

[taylorotwell]

@DougSisk any thoughts here?

[DougSisk]

It seems like since the broadcast manager doesn't use a dispatcher it's pushing right onto the queue. I'm guessing the best option would be to acquire the lock within BroadcastManager\queue() and continue to not use a dispatcher?