dht

Creating a new issue based on lbryio/lbry-sdk#877

• Update ensure_directory_exists() to check that the directory is writable by the current process.
• If it's not, return a useful error
• Add tests to cover the case when
  • download directory does not exist
  • download dir exists but is not writable
  • dir exists an

Because in CliClient.resume() we don't account for the case, when there is an exception in one of the async processing stages:

void resume() {
	...
	try {
		client.startAsync(state -> {
			printer.ifPresent(p -> p.print(state));
			if (!options.shouldSeedAfterDownloaded() && state.getPiecesRemaining() == 0) {
				runtime.shutdown();
			}
		}, 1000); // <-- CompletableFuture.w

Currently we don't have any mechanism to limit the maximum number of clients that could be handled simultaneously.

This feature should be designed properly. Here is some clue: https://redis.io/topics/clients#maximum-number-of-clients

Simple mistakes trigger unclear error messages in the ALBERT example, that is:

• Absence of the unpacked data for trainer (currently triggers requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://huggingface.co/api/models/data/tokenizer)
• Running all peers in --client_mode (currently triggers AllReduce failed: could not find a group)

It would be great to

众所周知，tracker也是会被封的，所以每天获取有效的tracker能提高效率，至于tracker列表的获取，看这个
https://hao.su/3278/

right now the debug log level is unusable, too much of it is spamming the logs, we need to downgrade the less informative ones to trace level.