feat: preserve tags for negated lines in config_to_get_to

[Frazew]

Summary

This PR introduces the ability to selectively generate snippets of remediation configuration based on tags

Changes

The only significant change is that when negating a line in the remediation configuration (_config_to_get_to_left), we preserve the tags that were previously set on the now-negated HConfigChild.

Example

(note: this is mostly verbatim from the docstring written in the test case)

Consider the case where we want to selectively remediate only parts of a configuration, we have two options:

1. filter the generated and running configurations by tags, and create the remediation: this will work almost as expected but will fail spectacularly for some edge cases (see below)
2. create the remediation from the generated and running configurations, and then filter by tags on the remediation (which, as I have only just noticed, is available in remediation_config_filtered_text)

Option (1) can fail in the following example scenario:

• we want to remove a specific BGP neighbor configuration for 192.0.2.1
• we retrieve the running configuration which has that neighbor along with some other neighbor:

  router bgp 65535
  neighbor 192.0.2.1
    ...
  neighbor 192.0.2.2
    ...

• we get our generated configuration, which does NOT have that neighbor:

  router bgp 65535
  neighbor 192.0.2.2
    ...

• we create a tag:

  - add_tags: our_neighbor
  lineage:
    - equals: router bgp 65535
    - equals: neighbor 192.0.2.1

• we filter both configurations to only include the our_neighbor tag
• we generate the remediation configuration on the filtered configuration
• the remediation configuration is:

  no router bgp 65535

This happens because the generated configuration is completely empty once it is filtered: it does not contain this neighbor, hence it does not contain anything!

The right (?) approach is therefore to compute the remediation configuration and only filter it afterwards, which requires that we are able to tag it properly. remediation_config_filtered_text will re-run tagging on the remediation configuration, but this implies that our tags must also match remediation configurations (with its negations and other necessary artifacts). I believe that copying the tags to the remediation configuration when negating lines actually makes more sense.

Notes

• I'm interested to see if this might be the wrong approach and if I may actually be missing an obvious solution :smile:
• Thank you for this insanely powerful library!