Terminology cleanup: The import_control hook is now called preexport.

Once upon a time, far far away, there were the old Bird developers
discussing what direction of route flow shall be called import and
export. They decided to say "import to protocol" and "export to table"
when speaking about a protocol. When speaking about a table, they
spoke about "importing to table" and "exporting to protocol".

The latter terminology was adopted in configuration, then also the
bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now
it's 2018 and the terminology is the latter. Import is from protocol to
table, export is from table to protocol. Anyway, there was still an
import_control hook which executed right before route export.

One thing is funny. There are two commits in April 1999 with just two
minutes between them. The older announces the final settlement
on config terminology, the newer uses the other definition. Let's see
their commit messages as the git-log tool shows them (the newer first):

    commit 9e0e485e50
    Author: Martin Mares <mj@ucw.cz>
    Date:   Mon Apr 5 20:17:59 1999 +0000

	Added some new protocol hooks (look at the comments for better explanation):

		make_tmp_attrs          Convert inline attributes to ea_list
		store_tmp_attrs         Convert ea_list to inline attributes
		import_control          Pre-import decisions

    commit 5056c559c4
    Author: Martin Mares <mj@ucw.cz>
    Date:   Mon Apr 5 20:15:31 1999 +0000

	Changed syntax of attaching filters to protocols to hopefully the final
	version:

		EXPORT <filter-spec>    for outbound routes (i.e., those announced
					by BIRD to the rest of the world).
		IMPORT <filter-spec>    for inbound routes (i.e., those imported
					by BIRD from the rest of the world).

	where <filter-spec> is one of:

		ALL                     pass all routes
		NONE                    drop all routes
		FILTER <name>           use named filter
		FILTER { <filter> }     use explicitly defined filter

	For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes
	the kernel protocol, so that you need to add EXPORT ALL to get the previous
	configuration of kernel syncer (as usually, see doc/bird.conf.example for
	a bird.conf example :)).

Let's say RIP to this almost 19-years-old inconsistency. For now, if you
import a route, it is always from protocol to table. If you export a
route, it is always from table to protocol.

And they lived happily ever after.

nest/rt-table.c

@@ -407,7 +407,7 @@ export_filter_(struct channel *c, rte *rt0, rte **rt_free, linpool *pool, int si
 
   rte_make_tmp_attrs(&rt, pool);
 
-  v = p->import_control ? p->import_control(p, &rt, pool) : 0;
+  v = p->preexport ? p->preexport(p, &rt, pool) : 0;
   if (v < 0)
     {
       if (silent)
@@ -873,7 +873,7 @@ rt_notify_merged(struct channel *c, net *net, rte *new_changed, rte *old_changed
  * routing table @tab) changes In that case @old stores the old route
  * from the same protocol.
  *
- * For each appropriate protocol, we first call its import_control()
+ * For each appropriate protocol, we first call its preexport()
  * hook which performs basic checks on the route (each protocol has a
  * right to veto or force accept of the route before any filter is
  * asked) and adds default values of attributes specific to the new
@@ -1473,7 +1473,7 @@ rt_examine(rtable *t, net_addr *a, struct proto *p, struct filter *filter)
 
   /* Rest is stripped down export_filter() */
   rte_make_tmp_attrs(&rt, rte_update_pool);
-  int v = p->import_control ? p->import_control(p, &rt, rte_update_pool) : 0;
+  int v = p->preexport ? p->preexport(p, &rt, rte_update_pool) : 0;
   if (v == RIC_PROCESS)
     v = (f_run(filter, &rt, rte_update_pool, FF_SILENT) <= F_ACCEPT);