feat(stream)!: remove limit on concurrent sessions and allow quitting apps with active sessions

[cgutman]

Description

This PR reworks session handling to be more flexible in the following cases:

• A user has existing streaming sessions and would like to connect a new client. This would fail with the default value of channels prior to this PR and the user would need to go manually disconnect that session.
• A user left a stream idle on another device and would like to quit the game they are streaming. That would fail until all active sessions have disconnected (and apprently in some other situation where session management broke: Cant close connection sometimes, error 503 moonlight-stream/moonlight-qt#1279)

This removes the channels configuration options and allows users to connect as many session as they want (up to the arbitrary limit of 128). They can also now quit the running app (which also disconnects all sessions) even if a session is still connected.

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

[codecov]

Codecov Report

Attention: Patch coverage is 4.34783% with 22 lines in your changes missing coverage. Please review.

Project coverage is 11.14%. Comparing base (d2be83f) to head (36e31c6).
Report is 95 commits behind head on master.

Files with missing lines	Patch %	Lines
src/rtsp.cpp	5.26%	10 Missing and 8 partials ⚠️
src/network.cpp	0.00%	1 Missing and 1 partial ⚠️
src/nvhttp.cpp	0.00%	0 Missing and 1 partial ⚠️
src/stream.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3325      +/-   ##
==========================================
+ Coverage   11.13%   11.14%   +0.01%     
==========================================
  Files          99       99              
  Lines       17211    17184      -27     
  Branches     8023     8009      -14     
==========================================
  Hits         1916     1916              
+ Misses      12594    12581      -13     
+ Partials     2701     2687      -14     

Flag	Coverage Δ
Linux	8.45% <4.34%> (+0.02%)	⬆️
Windows	5.22% <0.00%> (+0.02%)	⬆️
macOS-13	13.63% <0.00%> (+0.02%)	⬆️
macOS-14	12.63% <0.00%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.cpp	5.69% <ø> (+<0.01%)	⬆️
src/config.h	0.00% <ø> (ø)
src/network.h	0.00% <ø> (ø)
src/rtsp.h	0.00% <ø> (ø)
src/nvhttp.cpp	1.39% <0.00%> (+0.02%)	⬆️
src/stream.cpp	3.79% <0.00%> (ø)
src/network.cpp	26.49% <0.00%> (ø)
src/rtsp.cpp	3.10% <5.26%> (+0.06%)	⬆️

[ReenigneArcher]

Can we, or are we, logging the count of active streams? 128 seems excessive and likely to cause huge performance degradation? Might be good to just have that in the logs so the helpers can clearly see it.

[cgutman]

Can we, or are we, logging the count of active streams?

Added logging in the latest commit.

128 seems excessive and likely to cause huge performance degradation?

The point of picking 128 wasn't that someone would actually want to stream to 128 clients. We have to pick some number because ENet allocates a fixed size array for holding peers. I picked 128 because it should be comfortably above other hardware and software limitations for almost any conceivable setup while not being excessively large and wasting memory. The intent is for users to hit the limits of their CPU/GPU/network before they would get near 128 clients.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New issue
1 New Code Smells (required ≤ 0)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint