Use the public_key:cacerts_get/0 function when appropriate

[lukebakken]

References:

• Verification of ssl client / server options could be more user friendly erlang/otp#8066
• OAuth 2: support multiple resources, extract an OAuth 2 client #10012 (comment)

API: https://www.erlang.org/doc/man/public_key#cacerts_get-0

Anywhere SSl/TLS is configured in RabbitMQ, if the user does not configure cacertfile or cacerts, RabbitMQ should automatically use public_key:cacerts_get/0 to load the system certificates.

If, after doing all of that, RabbitMQ could set verify to verify_none. Otherwise, the ssl functions will fail as reported in erlang/otp#8066

Note that I've never seen cacerts used in practice.

[michaelklishin]

I don't think that we should widely fall back to verify_none. Certainly not for client connections. using public_key:cacerts_get/0 as a fallback is a good idea.

[LoisSotoLopez]

We can work on implementing this one.

[michaelklishin]

@LoisSotoLopez we'd appreciate it. We have seen a case where this behavior would be very useful just earlier this week.

[michaelklishin]

#12557 #12564.

[michaelklishin]

Erlang 27.2 has some relevant improvements:

# public_key-1.17

The public_key-1.17 application can be applied independently of other
applications on a full OTP 27 installation.

## Improvements and New Features

- public_key:cacerts_load/1 can now be configured via the application
  environment.

  Own Id: OTP-19321
  Related Id(s): PR-8920

- On MacOS, CA certificates are now also loaded from the system keychain.

  Own Id: OTP-19375
  Related Id(s): PR-8844