[Bug] [Enhancement]: livestream logic bug in 2.0.0-beta.5 and beta.6 
### What happened?

Hi!

I think I have found a somewhat severe logic bug in the way local livestreams (Dufy uses the term p2p I think) are handled in the current beta. Please correct me if I'm wrong - but at least for me this happened multiple times.

My Hardware:
Eufy Battery Doorbell (T8210)

The way streamingDelegate.ts works now, consider the following situation (as said I'm only referring to local streams only and no RTSP streams):

1. You open HomeKit on your device and see the camera device as snapshot in the HomeKit-UI. Chances are high that a new snapshot will be requested, so the stream is started. This (for me at least) takes in total somewhere from 3-6 seconds.
2. In this timeframe the users touches the camera to open the livestream. Again the process of starting the local stream is executed.
3. The Snapshot is finally returned and the fetchSnapshot function calls stopStationLivestream() on the EufyClient. This then results in alle the streams stopping. Including the one the user wanted to watch.

This happened several times to me. So I can confirm that this is an issue. Also I think many open issues for the beta could be explained with this.


I have implemented an alternative approach with some major advantages. I'll open a pull request with my changes and would like you to comment your view of the approach.

Here's a summary of what I've done to mitigate the issue (again all this applies only for p2p/local streams - rtsp remains untouched):

For every camera streaming delegate there is a new 'cached' livestream.
Once a livestream is requested it is opened via the startStationLivestream function but is not immediately stopped after one request is finished. Instead the cache keeps track of how many instances use the livestream and only stops it, when the livestream wasn't used  for a given time.
So the aforementioned scenario would go something like this:

1. The user opens HomeKit. The snapshot is requested and the cache starts the livestream.
2. The user clicks on the camera to watch the livestream. Now the livestream mustn't be loaded again, since the cache already had 1-2 seconds to do this.
3. The snapshot-request is fulfilled and releases one instance of livestream use. One instance remains since the user keeps watching the stream.
4. The user closes the stream. The cache now has no more instances that require the stream and starts a timeout to stop the stream.
5. After a few seconds a new snapshot is requested. Since the stream is still in the cache it can now be used instantaneously. (For me the snapshot requests came down to under a second from 3-6 seconds before)
6. The user closes HomeKit. Again no instance is requiring the stream so the cache sets a timeout to stop it. When this timeout fires, the livestream finally is released.

I have tested this with multiple devices using the same stream simultaneously and it not only works like a charm. It also reduces the start times of the streams enormously.

Advantages:
- Removes the aforementioned bug / behaviour.
- Reduces starting time for livestreams, after the stream was successfully cached.
- Could be implemented in such a way that camera events (motion, doorbell, ...) started the cached stream in advance (before the user opens HomeKit) - so starting times would (in theory) even be better than the native Eufy app

Drawbacks (of course there are some):
- slightly higher resource cost (cpu for HomeKit, maybe battery for battery powered devices - since the livestream would generally be running a bit more) - have not tested this and could imagine that this is negligible
- This approach somewhat conflicts with the maxCameraLivestreamDuration of the eufy client. If this setting is set to a low value, the cache will hardly be able to keep the stream running for long.
- Also if this setting is set to a high value it could result in a somewhat strange behavior for the user. For example:

1. The user opens HomeKit. The cache is started. For this scenario I assume a max livestream duration with Dufy of 10 minutes.
2. the users stays in the snapshot view for 5 minutes. The snapshots are frequently refreshed with the cached livestream.
3. Then the users clicks on the camera and watches the livestream.
4. After another 5 minutes the Dufy client would terminate the stream, since the total 10 minutes would be over. This would be counterintuitive for the users, since he had set 10 minutes in the configuration.

Nonetheless I'd favor this approach more. I'd imagine that this would not be the usual use case of most users.
Also I have tried to mitigate this new issue by letting the cache calculate how much time of the max livestream duration remains. If there is not sufficient time left when the last instance releases it's stream then the cache will immediately
stop the stream and the whole process will start over.

Again. I'm open to suggestions for improvement and try to open a pull request for my approach (will be my first pr, so be gentle with me :-)

edit: Pull Request added:   #31 

### Device Type

Doorbell (Supported)

### Plugin Version

beta (Best Effort)

### HomeBridge Version

v1.4.x (Supported)

### NodeJS Version

v16 (Supported)

### Operating System

Debian 10+ (Supported)

### Relevant log output

_No response_