How to practically handle validation of revoked certificates?

A MITM attack is not avoided with a revocation check.

To prevent a MITM you need to include the server root CA certificate in the client truststore and check that the server certificate has been issued by a trusted CA (present in your truststore). You can include also the server certificate in the truststore. A revocation check could make sense in the case that the attacker had stolen the certificate

1) What kind of protocols are widely used as OCSP "transport layer" - I know only HTTP - there are other competitive alternatives, which modern client should support?

HTTP and HTTPS

2) If I understand correctly CA will point in every certificate where to find CRL (except root CA / which is self signed) (in list of "CRL Distribution Points"?), so to implement strict client should I download CRL during certificate chain handshake. I know that for this purpose may be used HTTP and ldap - are there other competitive alternatives, which modern client need to support? ldap for this purpose is still common(or meybe this is just legacy)?

HTTP is the usual way. But it can be HTTP, FTP, LDAP, or FILE. LDAP is also used in some environments

3) Is in CRL way to detect how long it is valid, so can I cache it somehow for further connections?

CRL includes a nextUpdate field that indicates the date by which the next CRL will be issued

4) Is there practical way to work "offline" with CRL? As I understand to have it working in general, I should download(and update) CRL for every possible CA in world, which will require a much more resources/effort than doing so "online".

The usual way is to download the CRL when you need it, cache it and in the next check, check if you already have it

5) How deep may be typical certificate chain? Eg. more than for example 10 certificates in chain is possible?

There is no limit, but the usual value is 2-4

6) Does boost asio support somehow natively CRL and/or OCSP? I need to do this by myself?

There is no reference in the certificate verification section of asio so I'm afraid you'll have to implement it yourself

7) How in botan implement CRL "online" validation for cert chain? Maybe it is out of the box(as OCSP is implemented)?

OCSP is Online Certificate Status Protocol. In the web seem they refer to OCSP when they talk about online validation, but only CRL is supported

8) Both methods should be supported or meybe OCSP is used by most CA and CRL is defined by them only for legacy sw support reasons? If I would like just connect to 95% servers, then I need implement only OCSP and not care about CRL and reject certificates which cannot be verified using OCSP? Or maybe support for OCSP is relatively rare? As I found ocsp is supported for EV certs but not for OV and DV. That's true?

CA usually support OCSP & CRL. You need to support both. Even in the same CA it could be certificates that has to be checked with OCSP and others with CRL

9) Maybe I should check revocation both through OCSP and CRL if both available or just one "preferred" is enough?

OCSP is preferable because it is faster and uses fewer resources. The normal implementation is to launch a query in parallel to both services and use the response that came before