fixed crash when comparing two paths in the configuration dictionary
when the types were different - this had never been encountered before
but some recent changes for the border configuration exposed this

added supported for 'interface / fec' command

added some notices if debugging is enabled beyond the maximum level

tidied code, removing some unnecessary imports

also, introduced constants to better explain the dump rules levels in
the code

also corrects the maxmimum converter debug level in the help

parser, converter and unit test

if two paths being matched for changes have differing types at the same
position (e.g. one is a string and the other None) then this would
trigger a crash, when they try to be sorted

this fix converts the path elements to strings (with None being
converted to an empty string) so they can be compared

a unit test has been added to check for this, using the interface /
service-policy command with and without a 'type' option

this generates a warning but probably isn't causing any problems as the
only escape sequence used is '\d' which is only used in regexps and not
interpreted by plain strings

previously it would only be enabled if not, or removed if it should not
be enabled; now the situation where a switch requires it to be disabled
explicitly is handled

this still doesn't correctly handle defaults but does handle the
situation where it's explicitly set to the opposite state (just not
when it's explicitly set to the default state)

adds support for this command on routers, where it's disabled by
default (switches default to it being enabled, which we can't detect,
like 'switchport')

this reverses the conversion - going from the target configuration to
the source configuration

this can be useful to undo a conversion that has gone wrong

if a trigger fired a converter which has a different context, the
context the trigger fires in would not be checked against the matches
but, instead, the context of the converter, causing lots of spurious
triggers to run

this is not normally a problem (and hasn't been noticed until now) as
the context a trigger is set in will usually match that used by all the
converters in the block that it triggers, meaning they are the same

this is not always the case for some of the BGP converters, however, as
the classes for the converters can be reused in the 'bgp' context and
the 'address-family ... vrf ...' context (e.g. the 'neighbor ...
fall-over' converter)

this fix causes the context of a triggered converter to be checked to
ensure that it matches that which the trigger was set in

this was not handled correctly before (removing the route-map requires
that the entire command is removed and re-entered without it)

the case where shifting from 'neighbor ... fall-over route-map' to
'neighbor ... fall-over' was not handled correctly as this can only be
done by clearing the old command and entering the new; just entering
the new one does not remove the route-map

added tests to add and remove a route-map from a 'neighbor ...
fall-over' command

this involved a configuration dictionary change where both forms are
moved under a 'fall-out' -> 'route' key, then with a potential
'route-map' key under that, if there is a route-map specified, rather
than having a 'route-map' of None to indicate the plain form

this test was incorrect - testing for a configuration command sequence
that would not have resulted in the configuration checked for

(entering the plain form of the 'neighbor ... fall-out' command does
NOT remove the route-map option; a following update will handle this
situation in a converter)

now handles two commands enabling BFD: 'interface / bfd interval ...'
and 'route bgp / neighbor ... fall-over bfd'

the 'neighbor ... fall-over' command was generally broken as it handled
route-maps and BFD exclusively, whereas they can both be used on the
same neighbor

there is also some peculiar handling around the plain form of the
command (without 'bfd' or 'route-map' after) where it cannot be removed
without also removing a 'bfd' command, so a trigger is used to reapply
the BFD command

supporting this required an extra feature in the trigger mechanism,
where a trigger can be filtered at the point of being set (as opposed
to when it is fired on the triggered converter) which has been added
using the new converter trigger_set_filter() methods

fix: triggers matched the wrong context, if the context was dynamically
modified during construction

fix: removed some duplicate unittests

fix: an incorrect test name clashed with another and prevented one from
being run

tidy: some typos and tidying of comments and method/class names

parses and converts, added unittests

if a plain 'neighbor ... fall-over' configuration (without a route-map
or BFD) is removed, a BFD configuration will also be removed; this fix
will trigger the reapplication of the BFD configuration, following this

this required the ability to filter triggers from being set, in certain
situations

these methods are called on converters when trigger_blocks is
configured on them - only if they return True will the trigger actually
be set up

they are called with the same parameters as an action method (the old,
new, remove/update configurations, as well as the context and local
argumented)

these differ from the filter() methods as they are called on the
converter setting up the trigger, rather than the converter upon which
the trigger is applied (i.e. the triggered conversion) and are useful
to prevent a trigger from being set up under certain situations, based
on the triggering converter

fix: explicit_context_matches() now retrieves the computed context at
runtime, rather than the static context configured in the class (which
is important, if the class dynamically modifies its context upon
instantiation)

tidy: some converter debugging messages around triggers to make them
clearer

this is used in the 'router bgp ...' / 'neighbor ...' converter methods
to create versions for both the global and VRF address-families (where
things are added to the command or context, respectively, as these are
handled differently by IOS)

the recent change to introduce a subcontext for 'neighbor ...
fall-over' means this method is not just used to add the 'neighbor'
part to the relevant part of the path, so corrects the name in how
it's now used

in addition, the method is for internal use only, during construction,
so has '_init' on the start to make that clearer

previously, 'neighbor ... fall-over' with BFD and route-map options
were treated as mutually exclusive and the use of one replaced the
other - this is not the case and both can exist independently

in addition, 'neighbor ... fall-over' (without either option) is
really a particular case of the route-map version (matching if there is
no route to the neighbor, rather than a change related to a specific
route-map) - this fixes that

note that there is still a bug here - if the plain form ('neighbor ...
fall-over') is removed, this will cancel the BFD configuration: there
is no way to actually do this in IOS, so it is necessary to clear it
and then restore the BFD configuration - this needs to be fixed,
probably with a trigger

these were in the test file twice with the same name (except for one
with a missing character in the name) and only one was being run

improves consistency and clarity

one of the global AF command tests had the wrong name, clashing with a
VRF test and causing one of them not to run

also, tidying - moved into section of global AF commands, rather than
in the block of VRF AF commands

previously this didn't correctly handle when using BFD but without a
type (single- or multi-hop)

also, it didn't handle a combination of BFD and route-map usage: these
can be used at the same time

these are really plain commands and not contexts, so the name of the
classes was wrong

this doesn't actually break anything but is confusing and inconsistent!

BGP remote-as for a peer-group is now configured before adding peers
(as this would otherwise generate an error and the neighbor not added)

this was the case for peers inside a VRF but not in the global routing
table; this fix ensures that the remote-as is now configured before
adding neighbors, in the same way

one file per protocol or command family as the single file was getting
too long

the unit tests depend on deepops>=1.8 to pass, so this updates that as
a dependency

also, the conversion debug messages have been tidied a little

version 1.8 changes what happens when identical data structures are
compared, returning an empty object of the same type, rather than None

this probably doesn't affect anything that actually uses asimtote but,
without this, some of the unit tests fail and that's confusing!

removed 'match' to make messages shorter

rearranged trigger message to put match first and block name afterwards
in square brackets (to make more consistent with other messages)

this should have no effect on functionality

tidies the names of lots of internal classes and makes the call of
inherited context enter() methods better

better highlights abstract converters (_AbsCvt_xxx) and contexts

better use of split arguments (not assuming parent/context class
argument lists) and calls

context converters are now called Context_xxx

abstract command converters are now called _AbsCvt_xxx

still some tiyding to do against route-maps