maintained RpcReqError with headers in vkext

[DrDet]

Context

TL error serialization is historically totally broken and doesn't fit the scheme.
By according to TL scheme it must be like this:

kphp/common/tl-files/common.tl

Line 79 in c4031c7

reqError#b527877d {X:Type} error_code:int error:string = ReqResult X;

But actually it comes as:

kphp/common/tl-files/common.tl

Line 85 in c4031c7

rpcReqError#7ae432f5 {X:Type} query_id:long error_code:int error:string = RpcReqResult X;

rpcReqError#7ae432f5 is outer error, but it's fetched as inner one instead of reqError#b527877d, while latter is never used at all.

Problem

This weird deserialization is done via workaround as tl_fetch_lookup right before the answer fetching. And it's done inconsistently: if we require extra response headers via:

kphp/common/tl-files/common.tl

Line 47 in c4031c7

rpcInvokeReqExtra#f3ef81a9 {flags:#}

we will get the error on parsing them in case of the error, although in case of normal response everything is fine.

Changes

Now we can successfully fetch error with extra fields (header), if we require them.
In typed mode it's fetched as rpcResponseHeader object, containing rpcResponseError in its $result field.
It doesn't fit php-doc types, but it's fair, because it doesn't fit TL scheme at all.
This approach seems for me the best option, as it helps to avoid extra related workarounds in tl2php, tlo-parser, kphp, etc.
In kphp headers will just be skipped and rpcResponseError will be returned as usual.

---

In the future this workaround will be fixed, and serialization will fit the TL scheme and work correctly in kphp and vkext the same way.

[KokorinIlya]

Парсинг выглядит ок