Suppress unhelpful "unused variable" compiler warnings.

Added "Unused" macro for __attribute__((unused)) and applied
it to eliminate some ompiler warnings... on the basis that
the overall objective is to clean compile with zero warnings.

In some cases, attached TODO comments where the warning did
not seem entirely spurious.
Version number update: Quagga, 0.99.20ex26b

Changes since the last version include:

  * fixes for issues created when merging in 0.99.20

  * fixes to compile and run under FreeBSD

  * fixes for issues thrown up by OSRF ANVL tests

  * improved diagnostics for timers

  * updates to vtysh -- work in progress

  * detabbing some modules... see below.

Note on "detab"
===============

Some modules have been "detabbed", which is intended to make
it easier to merge the euro_ix branch with the main one.

The problem this addresses is: where an editor (eg the
Eclipse editor) automatically converts tabs to spaces and
discards trailing white-space, then when committing/merging
this creates entirely spurious changes, which clutter the
patches.

The detab process is entirely mechanical:

   * replace tabs by spaces -- assuming tab interval of 8.

   * replace all (remaining) control characters by '\n'.

     For ^L (FF) this generally introduces an (additional) blank
     line.

   * strip all trailing spaces

and is done by a little piece of perl, for all .c and .h files.

When the euro_ix stuff is merged with the main branch, if the
main branch is detabbed first, then a lot of spurious changes
can be suppressed.
Tidy up and reduce some warnings from compiler (and Eclipse)

All changes essentially cosmetic -- no change in function !!

Introduced "Unused" macro in lib/misc.h and used in various places to
kill off some spurious warnings.

Added more skips to lib/regex.c and regex-gnu.h to calm down Eclipse.

Other tidying up:

  * removing of CHECK_FLAG() clutter.

  * more consistent use of () around sub-expressions, in particular
    in boolean expressions.

  * comments tidied.

  * use of bool in some cases.

  * extern where is.
Small changes to unintern and free sub-attributes.

Make all the sub attribute free functions:

  * do nothing with NULL argument -- for consistency

  * return NULL -- likewise

Make all unintern functions:

  * cope cleanly with refcnt == 0 -- see below

  * take a indirect pointer and set NULL if frees value -- see below.

  * return NULL -- unconditionally

Add attr_refcnt_t so that all refcnt can be ensured consistent.

Replace aspath_empty() and aspath_empty_get() by aspath_empty(), now
with a bool argument to return an intern/unintern empty aspath.

A refcnt of 0 <=> a new value which has not yet been interned.  The
unintern function should honour that and simply discard the value.
Handling sets of attributes with a mix of interned and uninterned
values is tricky... but this does something predictable (does not
drive the refcnt -ve !) and plausible.

Some (not all) unintern functions took an indirect pointer, they now
all do.  If a sub-attribute is freed, and the parent attribute is
not freed or discarded, then we have ourselves a BUG.  However,
clearing the pointer at least means there is no dangling reference.

If an interned attr set has a sub-attr freed when the attr has a
reference count > 1, it will not be possible to unintern the attr,
because it won't be findable.  Much worse than that, the unintern
of the broken attr may find an unbroken set.  So, for attr and for
all sub-attr, during intern, if the attr or sub-attr are not
returned from the hash, nothing is freed.  This could remove an
unbroken attr/sub-attr, which at least stay in existence, but
will not be found when they are uninterned and any new instance
will grow a new hash entry.  The effect should be to leak memory,
but stay up.  These errors are now logged.
Tighten up handling of attribute sets, and temporary attribute sets

This does not actually change a great deal, but establishes the ground
rules for manipulating sets of attributes.

The problem is how to handle changes to a set of attributes, for example
changes implemented by a route-map.

The mechanism settled on is:

  * start with a set of attributes where all (existing) sub-attr are
    interned.

NB: the attr set itself does NOT need to be interned.

  * do bgp_attr_dup().  This does not change the state of the sub-attr,
    but creates a temporary copy of the given attr, where the
    temporary has refcnt == 0 (whatever given attr has).

  * make changes to the temporary attr:

  * simply replacing any interned sub-attr by new, uninterned
    values.

  * updating any uninterned values.  (Freeing as required.)

  * either:

  * interning the result -- bgp_attr_intern_temp()

  * discarding the result -- bgp_attr_flush()

AND then forgetting the temporary attributes.

The logic is that the original "owns" a refcnt on the original interned
sub-attr (so must not be uninterned until after the temporary
attributes have beed either interned or flushed).  While the temporary
has no refcnts of its own, but does "own" any uninterned sub-attr.

This is a little restrictive, but safe.

It is a rule that all sub-attr MUST have a refcnt >= the refcnt of
any give attr set (interned or not).

It is possible to unintern an attr which has refcnt == 0.  That will
unintern all sub-attr and free any whose refcnt is <= 1.  This may be
It is a rule that all sub-attr MUST have a refcnt >= the refcnt of
any give attr set (interned or not).

It is possible to unintern an attr which has refcnt == 0.  That will
unintern all sub-attr and free any whose refcnt is <= 1.  This may be
used when a attr set is constructed from scratch with interned
sub-attr (only), and is now to be dismantled -- see bgp_update_receive()

bgp_attr_unintern() used to take an indirect pointer, and clear that
if the attr was freed.  That was of little use.  Generally, after
uninterning the attr the caller has lost interest in the attr
altogether, so does not care whether it was removed from the hash
or not !

bgp_advertise_unintern () is brought into line with other unintern.
Tidy up attribute handling and route-map invocation in bgp_route.

This should work as before.

Parsed attributes have all sub-attributes interned, but are passed in
as an uninterned set.  At other times, fully interned sets are
handled -- eg at soft-reconfig.  It doesn't matter whether the
attr themselves are interned -- so that is fine.  Here we are careful
to ensure that we are handling attrs with interned sub-attrs, and
tread carefully through route-maps.

The peer->rmap_type handling was a bit magic... depending on it being
cleared after use and kept clear.  Have simplified that.
Return interned attr set from bgp_announce_check()

Also bgp_announce_check_rsclient().

This is a lot tidier than handling a temporary set of attributes
across a number of functions.

The existing code appears to work, so this should have minimal
impact.

It is essential that announcements for RS-Clients go into the
RS-CLient RIB, and not the Main RIB -- so added some qdebug checks
for that.

Return from bgp_process_announce_selected() was not required,
so changed that to void function.
Handle some attribute sets as 'const'

There are places where interned, partially interned or uninterned
attribute sets may be passed.  Provided these sets are not
changed in any way, all is well.  So... set 'const' to remind
ourselves of that and get the compiler to help.

Should not change behaviour.
Clean up how attributes are constructed for default/static/redistribute.

It is simpler to construct a temporary set of attributes with *nothing*
interned, then run that through the route-map stuff and intern the
result.

This saves some dicking about with interned aspath stuff.

For redistribute, having made a basic set of attributes, those are
interned, and then run through the route-map for each bgp instance.
So that changes made by the route-map can be identified and dealt
with correctly.

No change in behaviour, except for redistribution, where would be
different if there were more than one instance enabled for
redistribution -- which there isn't.
Review and fix sub-attr chages in route-map 'set' functions.

When applying a route-map, the rule is that:

  * all interned values "belong" to some other set of attr,
    so the can simply be replaced -- by uninterned values.

  * all uninterned values "belong" to this set of attr, so
    the 'set' function is responsible for freeing any
    uninterned values it replaces.

set as-path prepend was OK, but did not cope with the (screamingly
unlikely) case of a NULL as-path.

set as-path exclude likewise.

set community was almost OK, but leaked memory in the "none" case and
when replacing a community iff the community had already been changed
(and hence was uninterned).

set comm-list xxx delete was OK.

set extcommunity rt and set extcommunity soo were both BROKEN.  They
uninterned any existing value, which was not theirs to unintern, and
interned a new value, also wrong.
Review and tighten adj-out and advertisment handling.

The bgp_adj_out and bgp_advertise objects are closely bound together,
so that changes to the adj-out immediately start/stop/restart
advertisements on the relevant queue for the peer.  When an
advertisement is executed -- so an UPDATE message is sent to the peer,
the adj-out is updated (and after a withdraw, removed).  All the
pieces of information needed by the advertisement are locked by it,
so this is all nicely self contained, EXCEPT for the bgp_info
structure for update advertisements.

When a route is withdrawn its related bgp_info structure lives on
until it is given to bgp_info_reap() by the bgp_node process
function.  As far as one can see, all bgp_advertise objects
which refer to the reaped bgp_info will be stopped or turned into
withdraws -- and so drop their pointer to the bgp_info structure.

Just in case that does not happen, bgp_info_reap() now sets the
bgp_info to BGP_INFO_REAPED.  And if an advertisement is then
executed for a bgp_advertise object which points at such a bgp_info
it will be handled as a withdraw -- avoiding doing anything with
information which is definitely out of date !

There is no evidence that this ever happens.  But if it does, it is
now coped with AND logged as an error.
Change how bgp_announce_check() deals with Route Reflection & route-map.

When refelecting, the 'out' route-map is not allowed to change the
attributes.

This was being done by copying the temporary attributes to a second
temporary set, and then discarding that set.  That will fail if the
aspath has just been set to an empty path and the Route-Map then sets
something in the aspath -- because that will free the recently created
empty path, leaving a dangling pointer in the attribute set which is
about to be interned.  It would fail similarly if any other sub-attr
were uninterned.

So, the procedure now interns the attributes to date before applying
the route-map -- iff the route is being reflected.  If the route is
not denied, this is simply doing the necessary intern operation a step
or two earlier.
Update soft_reconfig handling for bgp_update_main()/_rsclient()

Add a 'soft_reconfig' argument to bgp_update_rsclient():

  * does not log duplicate as a doubtful update !

  * logs as "received" by soft reconfig.

For bgp_update_main():

  * avoid treating for route-flap damping.

  * do not log as a duplicate

  * also, for graceful restart, log as OK

  * logs as "received" by soft reconfig.

No actual change of behaviour, except for Route-Flap Damping.
Fix handling of BGP_INFO_ATTR_CHANGED in bgp_update_main()_rsclient()

When the same attributes arrive for a given prefix that does not mean
that BGP_INFO_ATTR_CHANGED should be cleared.
Improve announcement logic in bgp_process_rsclient()

Generally, if the selection has not changed and the attributes for the
current selection are not BGP_INFO_ATTR_CHANGED, the processing logic
will avoid generating an announcement.

This was not the case for ordinary Route-Server Clients, so a
Route-Server would send the same route more than once.  This is
corrected by this change.

For Groups of Route Server Clients, it did avoid sending duplicate
updates, but would check for the same thing for each group
member !  (OK, but a waste of time).

Further, for Groups of Route Server clients, made the unwarranted
assumption that all group members are members for all afi/safi,
which was seriously broken.
Improve announce logic in bgp_process_main().

Having decided on a new selection in the Main RIB,
bgp_process_main() announces the result to all peers, including all
RS-Clients.

This has all the appearance of a huge mistake.  However, it is probably
just a sad waste of effort.

bgp_process_announce_selected() runs bgp_announce_check() or
bgp_announce_check_rsclient(), depending in the table type for the
current bgp_node.  In this case, that is BGP_TABLE_MAIN, so the
route will be given to bgp_announce_check(), which will reject
it because it will not announce stuff from the Main RIB to any
RS-Client.  The result of that is to bgp_adj_out_unset()... which
will have nothing to do, because the RS-Client does not have
adj-out entries in the Main RIB.

So, for RS-Clients this is a lengthy-ish NO-OP !

Added a check to avoid calling bgp_process_announce_selected() in
bgp_process_main() for RS-Clients.
Review use of bgp_clear_rsclient_rib()

Changes made for greater clarity.  Function unaffected.

Name notwithstanding, this is not really a "clear" operation.

This is used when an RS-Client RIB has been emptied of all routes,
and the entire RIB is due to be freed.

Changed name to bgp_finish_rsclient_rib() and included the
bgp_table_finish() which always followed bgp_clear_rsclient_rib().

This function removes all routes contributed to the RS-Client RIB
by all peers.  There is a cosmetic change here:

 -  bgp_rib_remove (rn, ri, rsclient, table->afi, table->safi);
 +  bgp_rib_remove (rn, ri, ri->peer, table->afi, table->safi);

...bgp_rib_remove() is generally called with the peer which owns
the bgp_info (ri) -- the source peer.  The old code was calling
it with the peer which owns the RIB -- the destination peer.  As
it happens this makes no difference, the peer is only used to find
the bgp instance -- which is the same for both.

The function performs a belt-and-braces clear out of all adj-out
and adj-in.  All RS-Clients must have been cleared by this time,
so there should be no adj-out.  There should never be any adj-in.

In bgp_peer_delete() three loops dealing with RS-Client RIB have
been collapsed into one, without changing the effect but (hopefully)
clearer as to purpose.
Review bgp_clear_routes() and bgp_clear_adj_in()

bgp_clear_routes() clears all routes (a) contributed to all RIBs
by the given peer, and (b) announced to the given peer.  Added
some comments, but seems OK.

bgp_clear_adj_in() removes the remembered state of routes as
received from the given peer.  This information lives in the
Main RIB.  Previous code walked the main RIB looking for adj-in
entries.  New code uses the list of known adj-in for the peer
(as used elsewhere for clearing the peer).

Behaviour should be unaffected.
Fix MPLS and RS-Client and Soft-Reconfig.

For soft-reconfig the adj-in now carries a copy of the tag as
received from the peer.

[Previous code seems to assume that there will be a bgp_info,
and that its tag should be used.  It's not clear that there
will be a bgp_info -- since the route in the adj-in may have
been filtered out !  It's not clear that there will be only
one bgp_info -- so it's not clear who's tag this is using.
The previous behaviour appears broken.]

Soft-reconfig operations now use the tag in the adj-in.

RS-Client soft-reconfig will now work for MPLS RS !

The bgp_finish_rsclient_rib() will now work for MPLS RS !

[It is not clear that for non-RS MPLS RIBs that those are
correctly dismantled.  There does not seem to be a mechanism
to clear out redundant RD entries, or a mechanism to walk two
levels of table to dismantle same.]

bgp_update_main()/_rsclient() will now detect MPLS tag changes
as well as attribute changes.  Previous code would not notice
a tag change if the attributes did not also change !
Review bgp_announce_route()

This did something peculiar.  For RS-Clients it processed the Main RIB
and attempted to announce the current selection for all prefixes.
This would have been a disaster, except that it used
bgp_announce_check() -- the correct check for the Main RIB -- which
denies all MAIN RIB routes to RS-Clients.  So the result is just to
waste a certain amount of time.  Afterwards, for RS-Clients it would
then announce the RS-Client RIB.

The code now announces the Main RIB to Main RIB peers, and the RS-RIB
to RS-Clients.

For MPLS RS-Clients the code was broken, and has now been corrected.