frr: merge frr-libfrr and frr-vtysh to frr

[httpstorm]

Maintainer: @lucize
Compile tested: (x86_64, OpenWrt main)
Host tested: macOS 14.4.1

frr-libfrr and frr-vtysh are required components, which makes their menuconfig entries obsolete.
Merge them in the frr package.

Fixes: grep warning in frrcommon.sh grep: warning: stray \ before -

Fixes: [1]

lib/vty.c: In function 'vty_mgmt_resume_response':
lib/vty.c:195:27: error: 'VTYSH_READ' undeclared (first use in this function); did you mean 'VTY_READ'?
  195 |                 vty_event(VTYSH_READ, vty);
      |                           ^~~~~~~~~~
      |                           VTY_READ

The error is a bug in frr: not all use cases of the VTYSH_* enums are guarded by #ifdef VTYSH. These enums are enabled by the VTYSH macro, which is defined if sub package frr-vtysh is enabled in menuconfig. According to support ticket [2], building without frr-vtysh is no longer supported.

[1] #24063
[2] FRRouting/frr#15752 (comment)

Edit: I was asked to drop the update to frr-10 from this PR.

@robimarko @neheb @trippleflux

[httpstorm]

@robimarko
Robi, I will be on a vacation for a few days, maybe more. Please review the changes in the PR and feel free to take it from here. Best of luck!

[httpstorm]

@trippleflux
Please test, I do not have the environment to test exterior gateway protocols, such as BGP and others provided by frr.

[httpstorm]

I'm not sure how important staticd is for the work of frr, but if it is not installed, I see this error when the frr daemon is started:

/etc/init.d/frr start
cannot start staticd: daemon binary not installed
Started watchfrr

Affects both frr-9 and frr-10. One approach is to enable it by default, but the binary is 1.2MB:

diff --git a/net/frr/Makefile b/net/frr/Makefile
index 6fb17a313..bb50fca6b 100644
--- a/net/frr/Makefile
+++ b/net/frr/Makefile
@@ -129,6 +129,7 @@ define BuildDaemon
 	$$(call Package/frr/Default)
 	TITLE:= $(1) routing engine
 	DEPENDS+=$(2)
+	DEFAULT:=$(3)
     endef
 #	if [ "$(1)" == "bfdd" ]; then \
 #	export HAVE_BFDD == 1 ; fi
@@ -237,5 +238,5 @@ $(eval $(call BuildDaemon,pbrd,))
 $(eval $(call BuildDaemon,pimd,))
 $(eval $(call BuildDaemon,ripd,))
 $(eval $(call BuildDaemon,ripngd,@IPV6))
-$(eval $(call BuildDaemon,staticd,))
+$(eval $(call BuildDaemon,staticd,,y))
 $(eval $(call BuildDaemon,vrrpd,))

[trippleflux]

@httpstorm
I am regret to say that I am also currently don't have such BGP access to test into, I currently just compiling for now and doing normal connect into my ISP pppoe thing.

[EDIT]
Will do compilation test for x86_64.

It compile and run on x86_64, functionalities wise haven't tested as mentioned above.

[httpstorm]

@lucize @robimarko @neheb @PolynomialDivision @1715173329 @trippleflux
I rearranged the commits, so that fixes are applied before upgrading to version 10.
Please let me know if any changes are needed.
Can anyone do a test run?

Edit: dropped the upgrade to frr-10 as requested.

[lucize]

@httpstorm thanks for the commit, but please keep the versioning as before, the ideea is that frr is releasing major versions very slowly and that's why I used the stable branch based on date (hash of the specific date) so I can merge stable commits at somewhat regular intervals.
I'll do a test asap, just came back from holidays

[httpstorm]

@lucize
I agree it's better to drop the update to frr-10 here, and then you can take this step when everything is well tested.

Notes for future upgrades to frr-10:
Due to package dependency, we need to update to libyang >= 2.1.128, I tested libyang-2.1.148, which is the latest 2.1.* release. frr is not compatible with libyang-2.2.8 yet due to an API change in struct ly_err_item [1]. This is a limiting factor when we decide to update the following packages that depend on libyang. Currently they build correctly with libyang-2.1.148:

yanglint libnetconf2 libsysrepo sysrepo sysrepocfg sysrepoctl netopeer2-cli netopeer2-server

There is a build error in frr-10 that can be fixed using an upstream patch [2]

vtysh/vtysh.c: In function 'vtysh_init_vty':
vtysh/vtysh.c:5067:23: error: 'rpki_vrf_node' undeclared (first use in this function); did you mean 'vrf_node'?
 5067 |         install_node(&rpki_vrf_node);
      |                       ^~~~~~~~~~~~~
      |                       vrf_node

[1] CESNET/libyang@7a26677#diff-67a354ecb35f341abf57f84bd0d714b05280fddb1063b90a31f0d3ef67675bd7
[2] FRRouting/frr@d9d6db4

[lucize]

LGTM