Two reasons:
- There's some rare race condition in the queue implementation
- Doesn't scale and current performance is almost the same (-~2%)
- Created branch with the queue still retained for future inspection

This should be properly solved by better zone fetching API with
a) refcounting b) locking.

refs #31
fixes #30

Change-Id: Ic80408a129bf42e97b9e88392d318e89cfbad3e5

(changes in scanner intentionally skipped)

Change-Id: I6c24e78f37a6f7ad1dcb3429bb9dac14d5fb9ab9

Conflicts:
	configure.ac

Change-Id: Ic1b60bec6b85209040d4a270e45aa3f6e8f64e51

Change-Id: Ib10e0b882757c1fa3981dea20f29bf7179e4a2a5

Change-Id: Ibc52d1bbe6eb6510c81d0e46b1ce9f8a52cf6833

Change-Id: I53e7e891daf7fc4583bfecdb14276ae9e4b55147

Change-Id: Ib8a55d6df1266ca33d3fd6f1283489df3fa28d8a

This was wrong for cases like NSEC3 where no common suffix, like
the apex, is not in zone. Since the nodes are linked in circular
fashion, the easy solution is to find leftmost node and take it's
predecesor, which should be the rightmost node.

Change-Id: I5fa3714a889f159c682b255aeeef7d466f8be2ce

Signed could result to overflow in label length.

Change-Id: Ic1cae2c0df295127940fe1af74561690c0cddc30

Change-Id: I370ec936172d0d3a3422417010de6166810bcb72

7-bit ASCII is not enough to cover corner cases and potentially
harmful qnames.

Change-Id: I83a5af63e7ab3d2ce87c7b5063e55f1a1a6c2e1e

Change-Id: I8b934ca1f9cd0b80f7e1ede479674c269415f2da