Match autoconf build in terms of HAVE_AES macros

[botovq]

Noticed that this was missed when trying to run tests with cmake on an old core2 duo laptop. Apparently our CI doesn't run on such old targets.

[botovq]

I have no idea what's up with the cancelled and skipped CI. @joshuasing you're smart enough to deal with this stuff. Can you please take a look?

[joshuasing]

I have no idea what's up with the cancelled and skipped CI. @joshuasing you're smart enough to deal with this stuff. Can you please take a look?

Hmm, I'm not sure what caused that weird behaviour. I have re-run all of the jobs, so I'll see whether they all pass now.

This possibly could have been caused by the concurrency group not including the pull request number, and only the ref - but I am pretty sure the reference is the commit hash, so unless you also pushed the commit to another branch that triggered CI on this repository, I am not sure why it was cancelled. I will see if I can reproduce this so we don't have it happen again.

[botovq]

fwiw, it also happened twice in my fork: https://github.com/botovq/libressl-portable/tree/aes-asm

[botovq]

It also happened in the scheduled runs on the main repo https://github.com/libressl/portable/actions/runs/9278269374 Maybe it's just a hiccup in github's CI infra.

[joshuasing]

It also happened in the scheduled runs on the main repo libressl/portable/actions/runs/9278269374 Maybe it's just a hiccup in github's CI infra.

Wouldn't surprise me, however GitHub hasn't published an incident on their status page yet so I'm not sure.
It appears as so one of the runs was cancelled again, I think I will open a pull request to adjust the concurrency groups just in-case they're causing it.

[botovq]

actions/runner-images#9959