Error rebuilding FRR after clean

[gpaussabrcm]

Description
The SONiC FRR code can only be built from a fresh clone, but causes a build error when rebuilding after a clean operation.

Steps to reproduce the issue:

1. Build SONiC normally (I'm using PLATFORM=broadcom, but the platform shouldn't matter).
2. make target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb-clean
3. make target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb

Describe the results you received:

[FAIL LOG START ] [ target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb ]
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/sonic/src/sonic-frr'                               
# Build the package                                                              
pushd ./frr                                                                      
patch -p1 < ../patch/0001-Add-support-of-bgp-tcp-DSCP-value.patch
patch -p1 < ../patch/0002-Reduce-severity-of-Vty-connected-from-message.patch
patch -p1 < ../patch/0003-ignore-nexthop-attribute-when-NLRI-is-present.patch
patch -p1 < ../patch/0004-Allow-BGP-attr-NEXT_HOP-to-be-0.0.0.0-due-to-allevia.patch
patch -p1 < ../patch/0005-Support-VRF.patch
tools/tarsource.sh -V -e '-sonic'
dpkg-buildpackage -rfakeroot -b -us -uc -Ppkg.frr.nortrlib -j8
popd
mv frr-pythontools_7.0.1-sonic-0_all.deb frr-dbgsym_7.0.1-sonic-0_amd64.deb frr-snmp_7.0.1-sonic-0_amd64.deb frr-snmp-dbgsym_7.0.1-sonic-0_amd64.deb frr_7.0.1-sonic-0_amd64.deb /sonic/target/debs/stretch/
/sonic/src/sonic-frr/frr /sonic/src/sonic-frr
patching file bgpd/bgp_network.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file bgpd/bgp_network.c.rej
patching file bgpd/bgp_vty.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file bgpd/bgp_vty.c.rej
patching file bgpd/bgpd.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file bgpd/bgpd.c.rej
patching file bgpd/bgpd.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file bgpd/bgpd.h.rej
Makefile:9: recipe for target '/sonic/target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb' failed
make[1]: *** [/sonic/target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb] Error 1
make[1]: Leaving directory '/sonic/src/sonic-frr'
[  FAIL LOG END  ] [ target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb ]

Describe the results you expected:
Should be able to build FRR without error after doing a clean-type operation (e.g. make clean, make target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb-clean, rm -f target/debs/stretch/frr_7.0.1-sonic-0_amd64.deb, etc.).

Additional information you deem important (e.g. issue happens only occasionally):

This problem appears to have been introduced by PR-3017, where several patches are now being applied directly to the FRR source files. These patches apply cleanly the first time, when a fresh clone is used, but fail to apply in subsequent builds once the FRR source files have already been patched. This is causing the FRR rebuild process to fail.

Most other SONiC patched code relies on a source tree being downloaded fresh each time a given package is built/rebuilt, thus allowing the patches to be applied to unmodified source files. FRR stores its source files within the submodule repo, therefore the src/sonic-frr/Makefile cannot do an 'rm -rf' to start its build from a clean slate each time.

(Since the FRR source files are committed as part of the sonic-frr submodule repo, why is a patch process being used instead of just modifying the affected source files themselves within the branch?)

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```