NetDb: Provide Explicit Nesting of Conditional.

Use explicit nesting to get the desired if-then-else behavior, and reduce the log level for the normal case.

requested review from @zzz

assigned to @idk

Thanks for the review request. I don't really understand the title, I guess it's the name of the first commit. But this MR depends on other changes I haven't reviewed so it's a little tough.

But let's look at the first file changed - RouterInfoHandler:

-            outParams.put("i2p.router.netdb.knownpeers", Math.max(_context.netDb().getKnownRouters(null) - 1, 0));
+            outParams.put("i2p.router.netdb.knownpeers", Math.max(_context.netDbSegmentor().getKnownRouters(null) - 1, 0));

Huh? What's wrong with the way it used to be before all these changes, which was ctx.netDb().getKnownRouters()? Why in the world would you go thru the segmentor passing null in to get to the main db? And I'm recommending in multiple tickets that you remove the 5 alternate ways to get to the main db. This is going the other direction.

-            if (_context.netDb().floodfillEnabled())
+            if (_context.netDbSegmentor().floodfillEnabled())

Ditto. Why?????

So I'll stop here, you seem to be going in the opposite direction of what I've suggested. This is increasing not decreasing the code churn slash renaming extravaganza. There's also other issues that need to be resolved first, e.g. with BlindData #421 (closed), before you should go touching those calls.

NACK

mentioned in issue #402 (closed)

closing, subsumed by 2 months of changes

closed