upgrading config file according to the upstream

conf/config.yaml

@@ -30,6 +30,11 @@ log-level: "info"
 # Default: false
 log-db-queries: false
 
+# Bool. Include the client IP in the emitted log lines
+# Options: [true, false]
+# Default: true
+log-client-ip: true
+
 # String. Application name to use internally.
 # Examples: ["My Application","gotosocial"]
 # Default: "gotosocial"
@@ -764,6 +769,37 @@ syslog-protocol: "udp"
 # Default: "localhost:514"
 syslog-address: "localhost:514"
 
+##################################
+##### OBSERVABILITY SETTINGS #####
+##################################
+
+# String. Header name to use to extract a request or trace ID from. Typically set by a
+# loadbalancer or proxy.
+# Default: "X-Request-Id"
+request-id-header: "X-Request-Id"
+
+# Bool. Enable OpenTelemetry based tracing support.
+# Default: false
+tracing-enabled: false
+
+# String. Set the transport protocol for the tracing system. Can either be "grpc" for
+# OTLP gRPC or "jaeger" for jaeger based ingesters.
+# Options: ["grpc", "jaeger"]
+# Default: "grpc"
+tracing-transport: "grpc"
+
+# String. Endpoint of the trace ingester. When using the gRPC based transport, the
+# endpoint is usually a single address/port combination. For the jaeger transport it
+# should be a fully qualified URL.
+# OTLP gRPC or "jaeger" for jaeger based ingesters
+# Examples: ["localhost:4317", "http://localhost:14268/api/traces"]
+# Default: ""
+tracing-endpoint: ""
+
+# Bool. Disable HTTPS for the gRPC transport protocol.
+# Default: false
+tracing-insecure-transport: false
+
 #############################
 ##### ADVANCED SETTINGS #####
 #############################
@@ -841,3 +877,35 @@ advanced-throttling-multiplier: 8
 # Examples: [30s, 10s, 5s, 1m]
 # Default: 30s
 advanced-throttling-retry-after: "30s"
+
+# Int. CPU multiplier for the amount of goroutines to spawn in order to send messages via ActivityPub.
+# Messages will be batched so that at most multiplier * CPU count messages will be sent out at once.
+# This can be tuned to limit concurrent POSTing to remote inboxes, preventing your instance CPU
+# usage from skyrocketing when an account with many followers posts a new status.
+#
+# Messages are split among available senders, and each sender processes its assigned messages in serial.
+# For example, say a user with 1000 followers is on an instance with 2 CPUs. With the default multiplier
+# of 2, this means 4 senders would be in process at once on this instance. When the user creates a new post,
+# each sender would end up iterating through about 250 Create messages + delivering them to remote instances.
+#
+# If you set this to 0 or less, only 1 sender will be used regardless of CPU count. This may be
+# useful in cases where you are working with very tight network or CPU constraints.
+#
+# Example values for multiplier 2 (default):
+#
+# 1 cpu = 2 concurrent senders
+# 2 cpu = 4 concurrent senders
+# 4 cpu = 8 concurrent senders
+#
+# Example values for multiplier 4:
+#
+# 1 cpu = 4 concurrent senders
+# 2 cpu = 8 concurrent senders
+# 4 cpu = 16 concurrent senders
+#
+# Example values for multiplier <1:
+#
+# 1 cpu = 1 concurrent sender
+# 2 cpu = 1 concurrent sender
+# 4 cpu = 1 concurrent sender
+advanced-sender-multiplier: 2