Revert short acme order expiration time

What does this MR do?

Reverts !22878 (merged)

Shortening of an expiration time for acme orders made us hit Let's Encrypt rate limit for new orders: #197978 (closed)

We try to renew all these 917 domains every 2 hours, hit rate limit and retry every 15 minutes 🙈

[ gprd ] production> PagesDomain.need_auto_ssl_renewal.count
=> 917
[ gprd ] production> PagesDomain.need_auto_ssl_renewal.where.not(certificate:nil).count
=> 358

[ gprd ] production> PagesDomainAcmeOrder.expired.count
=> 154
[ gprd ] production> PagesDomainAcmeOrder.count
=> 770

The rate limit is:

For users of the ACME v2 API you can create a maximum of 300 New Orders per account per 3 hours. https://letsencrypt.org/docs/rate-limits/

Currently, we can make order expiration time about 9 hours (917 / 300 * 3), but I'd vote for just rolling back the change since the release date is very close.

And we'll need to expedite #30146 (closed)

Self-managed customers are unlikely to face the issue, but I think it's still better to revert this change in the %12.7, so I'm adding Pick into auto-deploy. Is this enough to push this MR to the release?

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team