Update dependencies, remove deprecations

[ibauersachs]

• Update dependencies
• Test on Java 17
• Remove deprecated usages of Smack and Kotlin
• Remove unused OSGi stuff¹

¹ actually, still somewhat used in Jigasi, but other OSGi things that were still used were already removed in e.g. #132. jitsi/jigasi#387 will handle this.

[codecov]

Codecov Report

Merging #157 (a04d890) into master (593325c) will increase coverage by 1.72%.
The diff coverage is 3.44%.

@@             Coverage Diff              @@
##             master     #157      +/-   ##
============================================
+ Coverage     18.54%   20.26%   +1.72%     
- Complexity       80       82       +2     
============================================
  Files            32       30       -2     
  Lines          1111     1120       +9     
  Branches        116      106      -10     
============================================
+ Hits            206      227      +21     
+ Misses          885      873      -12     
  Partials         20       20              

Impacted Files	Coverage Δ
.../main/java/org/jitsi/xmpp/mucclient/MucClient.java	0.00% <0.00%> (ø)
...oco/src/main/java/org/jitsi/xmpp/util/IQUtils.java	0.00% <0.00%> (ø)
...in/kotlin/org/jitsi/config/TypesafeConfigSource.kt	84.44% <100.00%> (ø)
...tsi/config/AbstractReadOnlyConfigurationService.kt	25.58% <0.00%> (-0.61%)	⬇️
...oco/src/main/kotlin/org/jitsi/rest/JettyHelpers.kt	0.00% <0.00%> (ø)
.../src/main/kotlin/org/jitsi/health/HealthChecker.kt	0.00% <0.00%> (ø)
...ig/src/main/kotlin/org/jitsi/config/JitsiConfig.kt	0.00% <0.00%> (ø)
...otlin/org/jitsi/rest/JettyBundleActivatorConfig.kt	0.00% <0.00%> (ø)
.../main/kotlin/org/jitsi/config/ConfigTestHelpers.kt	0.00% <0.00%> (ø)
...n/org/jitsi/config/ReadOnlyConfigurationService.kt	0.00% <0.00%> (ø)
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 593325c...a04d890. Read the comment docs.

[JonathanLennox]

In Smack, Stanza modification is synchronized, but builders are not. I haven't analyzed the threading model here, but is there any danger with this?

[ibauersachs]

Hm, good question. What do we actually need/want to keep from the presence packet, i.e. why is it intercepted and stored instead of always built from scratch?

I could synchronize on the builder while modifying the extension list and while calling .build(), but that's ugly :-/

[ibauersachs]

I'm really not sure who calls what here. There's some synchronization from MucClient and MucClientManager, but that's unlikely to be meant and usable for the presence object. I've added some synchronization that should be cheap enough to and not interfere with Smack.