fix(webrtc): Calculate maxBitrates based on HPBs maxstreambits

[nickvergessen]

☑️ Resolves

• Ref Return bandwidth information in room responses. strukturag/nextcloud-spreed-signaling#1099
• Ref Optimize camera resolution #16266

Unfortunately despite first successes the more I tested, the less it made a difference. I assume it's due to load on my machine

🏁 Checklist

• 🌏 Tested with different browsers / clients:
  • Chromium (Chrome / Edge / Opera / Brave)
  • Firefox
  • Safari
  • Talk Desktop
  • Integrations with Files sidebar and other apps
  • Not risky to browser differences / client

[fancycode]

Suggested change

	this.maxStreamBits = data.room.bandwidth.maxstreambitrate
	this.maxStreamBits = totalBps

Also you should reset this.maxStreamBits to the default value if no bandwidth limit is returned in the join response.

[Antreesy]

• Addressed comment (reset to default, if not provided)
• Extracted function to separate util
• Added lazy computation for Peer.offer() - where Firefox uses it - so bitrates are actualized right before the connection.

Noticed issues:

1. h:m:l are hard-cap values for Firefox simulcast connections - they can't get higher than allowed
2. With splitting 16:4:1, if h stream doesn't fit, bandwidth is under-utilized, m+l only using 5/21 of total
3. Making it more generous (h to 75%, m to 60%, l to 40%), so if h stream doesn't fit, it's fully utilized leads to following: m+l is taking 100% of bandwidth to sent, even if it's more than enough over the top for them - h is not sent
4. Setting back hard cap limits shows another thing: if h doesn't fit, base layer (l) takes over rest bandwidth
5. Removing maxbitrate completely from offer in attempt to let Firefox handle it correctly - h is not sent, m+l occupies full bandwidth, but now m layer is taking the bigger piece of it
6. Cap m and l, but allow Firefox to decide for h - second best result, but it oversaturates the bandwidth for h, leading to faster degradation of resolution (it prioritises fps) - CPU is the limit
7. Best found solution - keep m and l caps as before, allow h to read from total max bandwidth and take 90% of it (if h+m+l is overhead, it's ok, h either takes what's needed or will be dropped) - total sum may exceed 100%, but it is redistributed as needed
8. Alternative - pick a threshold (e.g. 1.5 Mb) - above it use 16:4:1 to ensure high is picked, below - 0:300kbps:100kbps

Results for Chrome (can be used, if we want to adjust mid/low):

4Mbps

(index)	rid	res	fps	cur_kbps	avg_kbps	active	limit
0	'-'	'640x360'	28	486	501	true	'none'
1	'-'	'1280x720'	28	2202	2473	true	'none'
2	'-'	'320x180'	28	144	150	true	'none'

2Mbps

(index)	rid	res	fps	cur_kbps	avg_kbps	active	limit
0	'-'	'1280x720'	29	1224	1187	true	'none'
1	'-'	'320x180'	30	129	142	true	'none'
2	'-'	'640x360'	29	454	475	true	'none'

1.5Mbps

(index)	rid	res	fps	cur_kbps	avg_kbps	active	limit
0	'-'	'1280x720'	30	797	793	true	'none'
1	'-'	'640x360'	30	475	476	true	'none'
2	'-'	'320x180'	30	144	143	true	'none'

1Mbps

(index)	rid	res	fps	cur_kbps	avg_kbps	active	limit
0	'-'	'?x?'	'-'	0	0	true	'bandwidth'
1	'-'	'320x180'	30	311	293	true	'bandwidth'
2	'-'	'640x360'	31	687	703	true	'bandwidth'

0.5Mbps

(index)	rid	res	fps	cur_kbps	avg_kbps	active	limit
0	'-'	'640x360'	29	337	321	true	'bandwidth'
1	'-'	'?x?'	'-'	0	0	true	'bandwidth'
2	'-'	'320x180'	30	164	146	true	'bandwidth'

TL;DR Change, affecting Firefox:

• high maxbitrate 900 kbps -> 90% of total (900 kbps with default total 1Mbps, grows with larger caps)
• medium 300 kbps -> 300 kbps
• low 100 kbps -> 100 kbps