Table: fix a race condition in export

Table: fix a race condition in export

The race condition happens as follows:

- channel A starts feeding
- channel B imports a route ahead of the feeding pointer
- channel A exports this route and continues feeding from the pointer
- no other import hits this specific prefix
- there is at least one channel C which has not cleared this export
- channel A computes ecnt=0 for this prefix because all exports
  have been already cleared
- the condition e >= ecnt mistakenly triggers retry

If the birdloops involved get assigned to the same thread, this race
condition then can't recover and the thread is stuck in an infinite
loop.

Fixed the race condition by moving the consistency check after actually
checking eligibility of the export, not before.

Found by randomly observing performance tests.