[WIP] Fix ban by software version, some other under-hood changes

- Use updated version of upstream go-xmpp + fixes on client-side
- Introduce golangci-lint v2 + fixes
- Move especially noisy debugging stuff to separate config handles to be able to switch them off
- Add a bit debug to ban by software path

vendor/golang.org/x/net/context/context.go

@@ -2,44 +2,9 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// Package context defines the Context type, which carries deadlines,
-// cancellation signals, and other request-scoped values across API boundaries
-// and between processes.
-// As of Go 1.7 this package is available in the standard library under the
-// name [context], and migrating to it can be done automatically with [go fix].
+// Package context has been superseded by the standard library [context] package.
 //
-// Incoming requests to a server should create a [Context], and outgoing
-// calls to servers should accept a Context. The chain of function
-// calls between them must propagate the Context, optionally replacing
-// it with a derived Context created using [WithCancel], [WithDeadline],
-// [WithTimeout], or [WithValue].
-//
-// Programs that use Contexts should follow these rules to keep interfaces
-// consistent across packages and enable static analysis tools to check context
-// propagation:
-//
-// Do not store Contexts inside a struct type; instead, pass a Context
-// explicitly to each function that needs it. This is discussed further in
-// https://go.dev/blog/context-and-structs. The Context should be the first
-// parameter, typically named ctx:
-//
-//	func DoSomething(ctx context.Context, arg Arg) error {
-//		// ... use ctx ...
-//	}
-//
-// Do not pass a nil [Context], even if a function permits it. Pass [context.TODO]
-// if you are unsure about which Context to use.
-//
-// Use context Values only for request-scoped data that transits processes and
-// APIs, not for passing optional parameters to functions.
-//
-// The same Context may be passed to functions running in different goroutines;
-// Contexts are safe for simultaneous use by multiple goroutines.
-//
-// See https://go.dev/blog/context for example code for a server that uses
-// Contexts.
-//
-// [go fix]: https://go.dev/cmd/go#hdr-Update_packages_to_use_new_APIs
+// Deprecated: Use the standard library context package instead.
 package context
 
 import (
@@ -51,36 +16,37 @@ import (
 // API boundaries.
 //
 // Context's methods may be called by multiple goroutines simultaneously.
+//
+//go:fix inline
 type Context = context.Context
 
 // Canceled is the error returned by [Context.Err] when the context is canceled
 // for some reason other than its deadline passing.
+//
+//go:fix inline
 var Canceled = context.Canceled
 
 // DeadlineExceeded is the error returned by [Context.Err] when the context is canceled
 // due to its deadline passing.
+//
+//go:fix inline
 var DeadlineExceeded = context.DeadlineExceeded
 
 // Background returns a non-nil, empty Context. It is never canceled, has no
 // values, and has no deadline. It is typically used by the main function,
 // initialization, and tests, and as the top-level Context for incoming
 // requests.
-func Background() Context {
-	return background
-}
+//
+//go:fix inline
+func Background() Context { return context.Background() }
 
 // TODO returns a non-nil, empty Context. Code should use context.TODO when
 // it's unclear which Context to use or it is not yet available (because the
 // surrounding function has not yet been extended to accept a Context
 // parameter).
-func TODO() Context {
-	return todo
-}
-
-var (
-	background = context.Background()
-	todo       = context.TODO()
-)
+//
+//go:fix inline
+func TODO() Context { return context.TODO() }
 
 // A CancelFunc tells an operation to abandon its work.
 // A CancelFunc does not wait for the work to stop.
@@ -95,6 +61,8 @@ type CancelFunc = context.CancelFunc
 //
 // Canceling this context releases resources associated with it, so code should
 // call cancel as soon as the operations running in this [Context] complete.
+//
+//go:fix inline
 func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
 	return context.WithCancel(parent)
 }
@@ -108,6 +76,8 @@ func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
 //
 // Canceling this context releases resources associated with it, so code should
 // call cancel as soon as the operations running in this [Context] complete.
+//
+//go:fix inline
 func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
 	return context.WithDeadline(parent, d)
 }
@@ -122,6 +92,8 @@ func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
 //		defer cancel()  // releases resources if slowOperation completes before timeout elapses
 //		return slowOperation(ctx)
 //	}
+//
+//go:fix inline
 func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
 	return context.WithTimeout(parent, timeout)
 }
@@ -139,6 +111,8 @@ func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
 // interface{}, context keys often have concrete type
 // struct{}. Alternatively, exported context key variables' static
 // type should be a pointer or interface.
+//
+//go:fix inline
 func WithValue(parent Context, key, val interface{}) Context {
 	return context.WithValue(parent, key, val)
 }