Summary:
Consider the following scenario.
Large transaction is committed. It starts apply procedure but in the middle of apply process the tserver is restarted.
After restart tserver continue to apply this transaction, but each write batch has null frontier, since we don't know apply operation id.
If we trigger flush on this tablet when there are no other writes happened (for instance because of intents sst cleanup), we would get crash.
Since our memtable flush filter expects that memtable should always have frontier.

Fixed by storing apply operation in transaction apply state and recover it after restart.
So we will always have non null frontiers while writing to RocksDB.

**Upgrade/Downgrade safety:** apply op id added to apply state protobuf. So if restarted happened with an old version, while transaction in the process of apply the issue still could appear after restart. Please note that it is not regression. It just means that issue considered as fixed if restart happens with a new version.
Jira: DB-6277

Test Plan: Jenkins

Reviewers: rthallam, esheng

Reviewed By: rthallam, esheng

Subscribers: yql, ybase

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D42097