[FRR] Move FRR GRE tunnel netdev setup into plugin initial templates

[jbemmel]

Include tunnel plugin frr.initial.j2 snippets from the FRR initial config, create GRE interfaces there instead of the module deploy script, and apply IPv6 sysctl settings to tunnel interfaces during initial configuration.

Mirrors the VyOS pattern, preparing for #3569

./device-module-test -d frr tunnel still passes for both clab and libvirt

[ipspace]

Why do you think this is needed? Also, did you try creating wireguard tunnels in the custom configuration template?

[jbemmel]

Why do you think this is needed?

It's needed to unify the treatment of interfaces. For example, MTU, IPv6 and RA settings aren't currently being applied to GRE tunnels, nor 'shutdown' flags.

The creation of devices is module or plugin specific, but once they're created certain common settings need to be applied consistently.

In case of WireGuard tunnels, configuring the keys early in the process also helps to reduce error logs of things like OSPF trying to do discovery over tunnels that are still down. It's not fool proof, but I think it's more consistent.

I separated this PR from the broader WireGuard PR because I figured you might prefer a small incremental change

[ipspace]

Why do you think this is needed?

It's needed to unify the treatment of interfaces.

I'm all for unified treatment, but why do you think the right solution is to include templates into initial device configuration? After all, VLANs have correct MTU on FRR ;)

The creation of devices is module or plugin specific, but once they're created certain common settings need to be applied consistently.

And we have a solution for that. Someone used it to configure IP address on SR Linux VLAN interfaces.

In case of WireGuard tunnels, configuring the keys early in the process also helps to reduce error logs of things like OSPF trying to do discovery over tunnels that are still down. It's not fool proof, but I think it's more consistent.

If you create the tunnel and configure keys in the same place, you won't have that problem. OSPF will not try to do discovery over a missing interface.

I separated this PR from the broader WireGuard PR because I figured you might prefer a small incremental change

Nothing wrong with that. It's just the wrong change ;)

You know what, now that I understand what's bothering you (and it's a valid concern), I'll clean up this stuff.

[jbemmel]

Replaced by #3589