This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

This reverts commit f0c9b40.

This reverts PR celery#6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

* Revert "Use Django DB max age connection setting"

This reverts commit f0c9b40.

This reverts PR #6134 and stops using the close_if_unusable_or_obsolete API since there are edge cases where it's
unable to detect if a connection if actually unusable. This is most obvious when Celery interrupts a query in
progress via a time limit handler. Django has marked this issue as
wontfix (https://code.djangoproject.com/ticket/30646). Since this is effectively an optimization for Celery that
can't be reliably used, Celery ought to close the connection after each task instead of trying to manage connections
in a way similar to how the Django application does.

* Ensure django fixup never calls close_if_unusable_or_obsolete

This API can fail to close unusable connections in certain scenarios,
namely database failovers and ungraceful terminations (e.g. signal
handler for time limit exceeded tasks). This makes
close_if_unusable_or_obsolete adequate for HTTP request lifecycle
management but inappropriate for use within celery workers.

See also:
https://code.djangoproject.com/ticket/30646
https://forum.djangoproject.com/t/close-if-unusable-or-obsolete-fails-to-close-unusable-connections/41900

* Add test for close_cache