VPP-873: fix vector expansion bug in dispatch_pending_node

VPP-873: fix vector expansion bug in dispatch_pending_node

The main interior graph-node dispatch loop had a longstanding dangling
vector element reference:

for (i = 0; i < _vec_len (nm->pending_frames); i++)
   cpu_time_now = dispatch_pending_node (vm, nm->pending_frames + i,
                               cpu_time_now);

Passing a pointer to a vector element (nm->pending_frames + i) has
considerable comedic potential if there's any chance that the vector
could expand.

dispatch_pending_node() calls dispatch_node(), and indirectly any
interior graph node dispatch function. If that node happens to expand
nm->pending_frames by filling in a new frame, nm->pending_frames can
expand.

After calling the node dispatch function, dispatch_node() does the
following:

  nf = vec_elt_at_index (nm->next_frames, p->next_frame_index);

If nm->pending_frames expands during dispatch function execution, p is
a dangling reference to freed memory.

By luck, the TCP stack managed to allocate a fresh frame which
included "old-p," which caused p->next_frame_index to be filled with
the new-frame poison pattern 0xfefefefe.

This has been broken from day 1, summer 2007, first use of the
third-generation vector processing library.

Change-Id: Ideb6363bb060c4e8bf9b901882c318bd83853121
Signed-off-by: Dave Barach <dave@barachs.net>