P.S. Looks like settings can be converted between SettingUInt64 and
SettingBool without breaking binary protocol?

Yes.

optimize_skip_unused_shards_nesting -- accept nesting level on which the
optimization will work
force_skip_optimize_shards_nesting -- accept nesting level on which
the optimization will work

Much better than optimize_skip_unused_shards=2

BTW, what is the setup when nested Distributed tables are required?
(the question from ClickHouse Meetup)

BTW, what is the setup when nested Distributed tables are required?

I was going to add some block about use case into the documentation (since there can be some interesting use cases and also caveats), but did not manage to find time for this, egh.

Anyway let me try to explain it briefly here:

Suppose you have lots of nodes (say 1000) in the cluster.
So what can you do in this case is divide your cluster of 1000 nodes, into smaller, for simplicity let's use 100 nodes per cluster, so 10 smaller cluster of 100 nodes. And the distribute data using some greatly-distributed-column (let's say user_id) between smaller clusters, and for this you will have two distributed tables, one that will distribute between smaller clusters (with sharding_key = consistent hash(user_id)), and distribute table in each cluster (let's use random distribution there for simplicity).
Then when you need to query your data you can use optimize_skip_unused_shards to avoid sending queries to all 1000 nodes, only to 100.

And one more advantage rise up when you need to expand the cluster (basically all above can be solved without nesting, but will require some trickery), since in this case you can just add new nodes into smaller cluster without any data re-sharding.

P.S. note that this a brief descriptions, that does not accounts some possible issues/aspects.

Yandex synchronization check (only for Yandex employees)

This is Ok.