Packer SSH Communicator Fails to Iterate Default KEX-algo list

#### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

#### Overview of the Issue

When using the ssh-communicator to provision a FIPS-enabled target, the SSH communicator hangs and eventually times out. If one logs into the target systems and reviews the system logs, one finds errors about:

~~~text
Apr 9 18:52:43 ip-172-31-47-57 sshd[1460]: input_kex_gen_init: Key exchange type c25519 is not allowed in FIPS mode [preauth]
Apr 9 18:52:43 ip-172-31-47-57 sshd[1460]: ssh_dispatch_run_fatal: Connection from 217.114.38.123 port 51540: invalid argument [preauth]
~~~

In `/var/log/secure`.

The problem may be worked around by using the [`ssh_key_exchange_algorithms`](https://developer.hashicorp.com/packer/docs/communicators/ssh#ssh_key_exchange_algorithms) parameter to specify an algorithm-list that omits `curve25519-sha256@libssh.org`. However, this _seems like_ it shouldn't be necessary. Since the documentation indicates that there's _already_ a list of algorithms to try, Packer notionally should attempt to iteratively renegotiate the connection to use one of the other ones in the list. This seems to not be the actual behavior.

Would request that any of:

- Packer attempts to iterate the default list to negotiate its connection
- Packer doesn't attempt to use weak KEX algorithms
- Packer's default algorithm list is ordered by algorithm, strongest to weakest

Be implemented.

While I did notice there were other communicator issues around FIPS-enabled systems, the nature/focus of those tickets seemed to be different.

#### Reproduction Steps

Steps to reproduce this issue
1. Run a packer-job that attempts to provision a FIPS-enabled target
2. Wait for Packer to hang while attempting to connect with the SSH communicator
3. Login to the target and view the `/var/log/secure` file: messages similar to the above will be found

### Packer version

1.8.7 (yes, I know that this is elderly but a few of our older job-defs won't work with newer versions: we're planning to remove them when Red Hat deprecates RHEL 7 in early summer)

### Simplified Packer Template

If the file is longer than a few dozen lines, please include the URL to the
[gist](https://gist.github.com/) of the log or use the [Github detailed
format](https://gist.github.com/ericclemmons/b146fe5da72ca1f706b2ef72a20ac39d)
instead of posting it directly in the issue.

### Operating system and Environment details

OS, Architecture, and any other information you can provide about the
environment.

Packer-executor host(s):
- Amazon CodeBuild
- Windows 11
- Oracle Linux 9
- OSX 14.4

Packer target(s):
- Red Hat 9 (FIPS-enabled)
- Oracle Linux 9 (FIPS-enabled)
- CentOS Stream 9 (FIPS-enabled)

### Log Fragments and crash.log files

~~~text
2024-04-09T07:00:34.812-07:00 amazon-ebs.minimal-ol-9-hvm: + pkill --signal HUP sshd
2024-04-09T07:15:36.926-07:00 ==> amazon-ebs.minimal-ol-9-hvm: Provisioning step had errors: Running the cleanup provisioner, if present...
[…elided…]
2024-04-09T07:55:35.990-07:00 Build 'amazon-ebs.minimal-centos-9stream-hvm' errored after 1 hour 1 minute: Timeout waiting for SSH.
~~~

Cc'ing: @lorengordon & @eemperor