…1377) (ydb-platform#1647)

Co-authored-by: nsofya <[email protected]>

…b-platform#2140)

Co-authored-by: Nikolay Shumkov <[email protected]>

…start race (ydb-platform#2169)

…db-platform#2232)

…) (ydb-platform#2305)

Co-authored-by: nsofya <[email protected]>
Co-authored-by: nsofya <[email protected]>

…atform#2174) - merge 24-1 (ydb-platform#2318)

ydb-platform#2382)

…tform#2412)

…2391)

Cherry-pick 3819aed from main (ydb-platform#2083).

Make schemeboard replicas consume less CPU, especially when processing rapid updates for tables with huge amount of partitions.

Schema information on a path exist in the form of `DescribeSchemeResult` object: schemeshard generates those objects and publishes them to the schemeboard, schemeboard notifies scheme-caches on the nodes about path info changes. So schemeshard generates `DescribeSchemeResult`, scheme-cache serves `DescribeSchemeResult` to the consumers. But schemeboard components in-between do not require the full content of a TEvDescribeSchemeResult to operate efficiently.

This update enables the schemeboard to transmit `DescribeSchemeResult` through as an opaque payload rather than as a fully detailed protobuf object. Thus reducing the unnecessary memory management and serialization/deserialization overhead.

ydb-platform#2472)

…latform#1960) (ydb-platform#2479)

KIKIMR-21002

In this PR we add the following algorithm for invalidating cache entries for outdated VIEWs:

1. Store path ids and schema versions of the views that were used in the query in the cache entries, so they can be accessed later.
2. Whenever we retrieve a compilation result from cache, send a request for SchemeCache to check if the schema version of the views used in this query (if any) has not changed since we compiled this query.
3. Send a recompilation request if any view is outdated.

There are two important things to note about this solution:

- We make a SchemeCache request for each repeated query and there is a lot of these in an OLTP-focused database like YDB. However, we have already been sending these request for preliminary (this is not the last check of schema version mismatch (at least for tables)) cache invalidation for tables, so views should not incur an additional performance impact here.
- This solution does not guarantee strong consistency for queries using views, because query cache invalidation will not happen instantly after the view definition is updated. The node should get an update from the SchemeCache, which takes some time.

ydb-platform#2540)

…db-platform#2574)

…db-platform#2629)

Co-authored-by: Andrey Neporada <[email protected]>

…tform#2624)

…lib (ydb-platform#2633)

…ment (ydb-platform#2049) (ydb-platform#2595)

Based on: ydb-platform#2049

KIKIMR-20891

CREATE VIEW statement parses (and validates) the select statement saved in the view. It should be parsed in a context isolated from the statements executed before the CREATE VIEW statement (we haven't decided yet on the exact scope of the context of the view's select statement, see [KIKIMR-20656](https://st.yandex-team.ru/KIKIMR-20656)). It is pretty obvious that one should be able to execute the following statement in one go ("one go" = one press of a "run" button in YDB UI):
```sql
-- create view NecessaryInnerView with (security_invoker = true) as select 1;
-- create view ContextTestingView with (security_invoker = true) as select * from `/local/NecessaryInnerView`; -- where `/local/...` is your cluster name

drop view ContextTestingView;
create view ContextTestingView with (security_invoker = true) as select * from `/local/NecessaryInnerView`;
```

However, executing both drop view and create view in one go currently produces and error:
```
DropObject is not yet implemented for intent determination transformer
```
which indicates that the context of the inner query:
```sql
select * from `/local/NecessaryInnerView`
```
is polluted by the previous:
```sql
drop view ContextTestingView;
```
statement.

This problem is fixed by using an empty parsing context for parsing view's inner select statement during handling of CREATE VIEW statement.

…#2750)

…db-platform#2790)

…#2816)

…-platform#2796)

…db-platform#2765. (ydb-platform#2839)

…-platform#2883)

…b-platform#2911)

Co-authored-by: Daniil Cherednik <[email protected]>
Co-authored-by: spuchin <[email protected]>

…platform#3006)

…m#2885. (ydb-platform#3074)

…rm#2929)

…db-platform#3154. (ydb-platform#3165)

Co-authored-by: Oleg Doronin <[email protected]>

…platform#3176)

… transactions (ydb-platform#3378)

…) (ydb-platform#3548)

…platform#3575)

…ained queue list budget in 24-1 (ydb-platform#3606)

…form#3632)

…tform#3700)

Co-authored-by: Nikolay Shestakov <[email protected]>

…b-platform#3853)

Co-authored-by: Andrey Neporada <[email protected]>

Co-authored-by: Sergey Veselov <[email protected]>

…-platform#3841) (ydb-platform#3917)

…orm#4105)

… merge-24-1 (ydb-platform#4130)

…4147)

…db-platform#4146)

…tform#4222)

Co-authored-by: DimasKovas <[email protected]>