Because the old case didn't account for the Scheduler got dropped but Participant keept around.
Shutdown behavior is quite easy now: bParticipant sends a oneshot, when that hits we stop. also when Participant gets droped we still stop as there woul dbe no sense in continue running the report_mgr ...
This will ask the bparticipant for a list of all channels and their respective connection arguments.
With that one could prob reach the remote side.
The data is gathered by scheduler (or channel for the listener code).
It requeres some read logs so we shouldn't abuse that function call.
in bparticipant we have a new manager that also properly shuts down as the Participant holds the sender to the respective receiver.
The sender is always dropped. inside the Mutex via disconnect and outside via Drop (we need 2 Options as otherwise we would create a runtime inside async context implicitly o.O )
(also i didn't liked the alternative by just overwriting the sender with a fake one, i want a propper Option that can be taken)
The code might also come handy in the future when we implement a auto-reconnect feature in the bparticipant.
* Old display_shortened that returned Option is now called try_shortened
* What was called try_shortened is now just display_shortest, because if
shortened version isn't available, it means that regular version is
already shortened.
* Make try_shortened method that tries shortened version of key or
regular version if shortened one isn't available
* Use it in most places where display_shortened + display_string were
used
* Use it for diary skilbar
* New hud/ability.ron file for ability localizations
* i18n keys are created by adding .name and .desc to ability id. Because
of how i18n worked (returning key if string wasn't found), it was
impossible to do because it leads to UB in case string is missed.
To solve this we've added get_opt method that returns None
* New Localization::get_or method for convinient fallback key usage
Note: maybe upgrading tokio helps against the connection issues, there is some mio related stuff: https://github.com/tokio-rs/tokio/releases/tag/tokio-1.18.0
Note: quick also still has the old read, but its more complicated, thus i only want to change it if its tested
Fixed title screen FPS cap not being applied correctly when background FPS limit is greater than the title screen cap
See merge request veloren/veloren!3442
We calculate a max bandwidth, but due to framing the packages, i think its possible for the current_bytes to get a few bytes over the actuall planed bandwidth. which prob isn't that bad/unfair
