Update dependency bunny to v3 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
bunny (source, changelog)	2.24.0 → 3.1.0

---

Release Notes

ruby-amqp/bunny (bunny)

v3.1.0

Compare Source

Modernization for Ruby 3.x

Contributed by @​eglitobias.

GitHub issue: #​735

amq-protocol Bump to 2.8.0

This version optimizes deserialization of a few frame types,
most benefitting applications that primarily consume messages.

Bug Fixes

Connection Recovery Survives connection.close During Negotiation and Repeated Failures Mid-Recovery

Overlapping (concurrent) connection recovery attempts could leave a client
permanently disconnected, in particular when target node was put into maintenance mode
which closes all client connections before the node is restarted.

Several changes address this scenario:

• Connection recovery now uses a mutex to avoid concurrent attempts
• The connection status is set to :open and the heartbeat sender is started
  only after connection.open-ok is actually received
• A connection.close received during negotiation with automatic recovery
  enabled is now raised in the recovery thread and handled by the recovery
  retry logic, instead of being delivered to the session error handler
• Socket read timeout is now applied early, which means that a disabled
  (by maintenance mode) protocol listener would not cause client connections
  to linger waiting for a socket event that will never arrive

In addition, a failure to redeclare a single entity during topology recovery no
longer aborts the entire recovery process and will catch transport timeout
exceptions.

Reader Loop No Longer Crashes on a Frameset for an Already Closed Channel

Session#handle_frameset now guards against a missing channel like Session#handle_frame already did.

GitHub issue: #​741

Bunny::Consumer Identity Preserved on Recovery

Consumers registered via Queue#subscribe_with or Channel#basic_consume_with
are no longer replaced with a freshly constructed Bunny::Consumer during
automatic connection recovery.

The original instance is restored, so callbacks such as on_cancellation defined
before recovery continue to function.

Contributed by @​jollopre.

GitHub issue: #​737

v3.0.0

Compare Source

on_error Callback Runs in a Separate Thread

Channel#on_error callbacks are now invoked in a separate thread
when triggered by the reader loop. This allows callbacks to perform
blocking operations such as Channel#reopen without deadlocking.

Internal Connection Recovery Improvements

A detected connection failure now immediately marks all channels
on the connection as closed.

This has no practical consequences for most applications but
helps make connection recovery tests more robust.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: Gemfile

Artifact update for bunny resolved to version 3.2.0, which is a pending version that has not yet passed the Minimum Release Age threshold.
Renovate was attempting to update to 3.1.0
This is (likely) not a bug in Renovate, but due to the way your project pins dependencies, _and_ how Renovate calls your package manager to update them.
Until Renovate supports specifying an exact update to your package manager (https://github.com/renovatebot/renovate/issues/41624), it is recommended to directly pin your dependencies (with `rangeStrategy=pin` for apps, or `rangeStrategy=widen` for libraries)
See also: https://docs.renovatebot.com/dependency-pinning/