issue-6874: deleting SessionEvents api and impl - #7514

• 🔴 filestore (build failed, log)

• ✅ filestore

🟢 linux-x86_64-relwithdebinfo target: cloud/filestore/ (test time: 7493s): all tests PASSED for commit 3f79d40.

temporarily agreed to merge w/o right team's approval

Claude:

Verdict: no serious issues. Nothing that carries an ID drifts. I checked every place where an identifier is persisted, sent over the wire, or generated from list position:

EFileStoreRequest (persisted in profile logs). Values are explicit. Slots 22, 23 and 48 become Reserved1/2/3 rather than being removed, so everything from ResetSession = 24 through AsyncDestroyHandle = 68 and MAX = 69 keeps its number. RequestNames[] keeps the old strings at those indices, and the static_assert on its size still holds. Old profile logs therefore decode with the same names. auth_scheme.cpp handles the Reserved values, so its switch can’t hit an unexpected value.
TEvService actor event IDs. Every event is written as EvBegin + N, not generated from the macro lists. 67–70 become EvReserved1..4, and EvRegisterLocalFileStore = EvBegin + 71 and everything after it is unchanged. Taking SubscribeSession out of FILESTORE_SERVICE_REQUESTS_FWD doesn’t renumber anything, because no event ID comes from macro order.
Macro lists. The only other code that iterates FILESTORE_REQUESTS is dump_ut.cpp. It looks names up by enum value, so it is unaffected.
Protobuf. The removed messages (TSessionEvent, TSubscribeSession*, TGetSessionEvents*) are deleted whole, and no remaining message referenced them, so no field numbers in surviving messages change. Removing gRPC/HTTP methods only affects those methods, since routing is by method name, not index.
Tablet state and commit IDs. GenerateEventId used the per-session LastEvent counter, not the tablet’s shared LastStep. So removing it doesn’t change commit-ID generation. LastEvent/NotifyEvents were in-memory only and never in the tablet DB schema, so there is no schema change. No tablet-private or TEvIndexTablet event IDs are touched.
Per-request counters still register over 0..FileStoreRequestCount. The reserved slots keep their old sensor names, so existing sensors don’t shift either.

The only behavioural change is during a rolling upgrade: a caller of the removed RPCs would get an “unimplemented” error. Since you said the API isn’t used, that doesn’t matter here.