FreeBSD CI support

[toor1245]

Checked another solutions to support FreeBSD CI:

• freebsd-vm: https://github.com/vmactions/freebsd-vm
• cross-platform-actions: https://github.com/cross-platform-actions/action

freebsd-vm:

It looks like this solution supports only amd64 architecture
https://github.com/vmactions/freebsd-builder/blob/main/conf/freebsd-14.1.conf#L3

However, in builder script there is VM_ARCH
https://github.com/vmactions/freebsd-builder/blob/f799d8fb9b84977ec8fa020178262de39eaa4b83/build.sh#L35

and upcoming features:

• Runs on MacOS to use cpu accelaration.
• Support ARM and other architecture.

Maybe it’s possible manually configure the architecture somehow, but at the moment it looks like a hardcoded architecture amd64

cross-platform-actions:

This action supports FreeBSD amd64 and arm64 architectures and we support these architectures for FreeBSD:
https://github.com/cross-platform-actions/action?tab=readme-ov-file#freebsd-freebsd

I used this solution, proof of success:

• FreeBSD amd64: https://github.com/toor1245/cpu_features/actions/runs/10652248435/job/29525815775#step:3:556
• FreeBSD arm64: https://github.com/toor1245/cpu_features/actions/runs/10652474246/job/29526357627#step:3:568

It worth noting that googletest doesn't work with bazel in FreeBSD, so we use only cmake in CI:
#295 (comment)

We can try to add only build for bazel.

[toor1245]

@gchatelet, @Mizux, could you please review PR?

[Mizux]

Sorry for the delay, still need to think about it...
Please see below my few pro and cons, i.e. my current thought about this PR:

On the bright side:
a) having two jobs working is better than nothing (or our previous broken one) -> Many thanks for taking the time to fix our BSD CI support !

b) leveraging github actions reduce our technical debt and reducing scripts length...

On the cons side:
c) Using actions means the migration/fork to another CVS (e.g. gitlab) make this more difficult, usually I prefer so stick with the bare minimum actions (i.e. checkout) and only from github (i.e. kind of "official" actions) then having everything in the .yml directly or inside a versioned script. i.e. minimize the vendor lock-in.

d) Using actions means we can't easily locally test or we need to maintain a second scripts with overlap to the github action...
-> I prefer to have a script to run locally and the CI is just a dumb runner which can run it for me.
-> I think, github actions often hide the two bash script lines needed to run it locally.
-> I'm biased with my Makefile + Docker/Vagrant CI setup ;)

e) vmactions/freebsd-builder seems brittle and may allow some supply chain attack (ed very low risk since we don't deploy or share/use any token). Actually, my main concern is more the test of time, AFAIK only "neil" seems to be the maintainer of this tooling and I don't like this kind of change where both repos need to be in sync...:
vmactions/freebsd-builder@3db1a35
https://github.com/vmactions/vbox/commits/main/ (only 2 stars -> not battle tested and brittle ?)

ps: Still want to explore vagrant on ubuntu-latest path too (in this case we could keep our ci/Makefile/Vagrant stuff just change the runner base image and do few setup)!
see: https://github.com/magma/magma/pull/15381/files#diff-6cea9de55c2b40b7e046ce2f3b096f80f3f7018ac52fa6e55ba11a6ffce4c6f7R105-R108

As usual feel free to comment any points and change my mind, I'm still thinking about it !
One scenario could be to accept this PR as "temporary" solution until we have a new PR challenging it ;)