bgpd: Fix GR when using R-bit with hard reset (adminstrative reset)

[ton31337]

Closes #18238

[Pdoijode]

@ton31337 with this code change, on the receiving peer even when F-bit is set in GR capability, it will end up deleting the stale routes, which is wrong!

To me, it looks like the F-bit was not set by the restarting node on session re-establishment. We may have to enable logs and check if that's the case and if it's indeed the case, then we'd have to debug why the restarting node didn't send F-bit if forwarding was indeed preserved.

Here's what the RFC says:

https://datatracker.ietf.org/doc/html/rfc4724#section-4.2 (Graceful Restart Mechanism for BGP):

   Once the session is re-established, if the "Forwarding State" bit for
   a specific address family is not set in the newly received Graceful
   Restart Capability, or if a specific address family is not included
   in the newly received Graceful Restart Capability, or if the Graceful
   Restart Capability is not received in the re-established session at
   all, then the Receiving Speaker MUST immediately remove all the stale
   routes from the peer that it is retaining for that address family.

https://datatracker.ietf.org/doc/html/rfc8538#section-4 (Notification Message Support for BGP Graceful Restart):

Once the session is re-established, both BGP speakers SHOULD set
   their Forwarding State bit to 1.  If the Forwarding State bit is not
   set, then, according to the procedures in [Section 4.2 of [RFC4724]](https://datatracker.ietf.org/doc/html/rfc4724#section-4.2),
   the relevant routes will be flushed, defeating the goals of this
   specification.