babeld: Convert all code to use our code formatting rules

[donaldsharp]

The babeld code was originally kept in a non-standard format, at least to how FRR formats code, because the code came from outside the project and it was hoped that updates would be coming from the originators. That has not turned out to be true and we've been slowly getting bug-fixes for the code over the last year
as it is being used. Let's just bite the bullet
and convert over to our internal format for consistency.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[riw777]

Waiting on Alistair's discussion with Juliez ...

[ahw59]

I spoke to Juliusz last Friday. Here are the takeaways

1. babeld is mature. The last feature work was back in 2023. No feature work is planned or proposed.
2. Juliusz doesn’t object to the FRR project normalizing the formatting of the babeld code
3. Juliusz does however reserve the right to ‘poke fun at us for busywork activities’ ;-)

[mjstapp]

we should remove the exception for checkpatch now?
tools/checkpatch.sh:ignore="ldpd\|babeld"

[mjstapp]

super, thanks

[donaldsharp]

checkpatch is wrong for this last one.

there are a series of if /else statements where some return and some don't. We should not remove the last else statement

[mjstapp]

yes, we talked about this in slack, and it's not worth refactoring the clause that's triggering that warning (right now)

checkpatch is wrong for this last one.

there are a series of if /else statements where some return and some don't. We should not remove the last else statement

[wiselongbeard]

Hello Team,
Amazing job converting Babel; However, afaik, current FRR 10.5 does expose destination-only options for Babel with no knobs available yet to configure RFC 9079 source-specific routing, doesn't it?
If that's the case, if I may ask, any future plans of supporting Babel's source-specific routing natively with FRR?
Thanks,