[docdb] Add rail guards to prevent restore if shared relations are modified

[sanketkedia]

Jira Link: DB-2082
For PITR support for YSQL, we support snapshots and recovery per database (to take care of indexes, related foreign key constraints, etc). However, Postgres has several shared tables that are not maintained at a per-database level but instead, there's one common relation shared by all the tables. For example, tablespaces and roles fall under this purview. If such tables are modified and we want to restore a database such that these need to be changed then we aren't sure if we want to support it or not. For starters, it can have side effects that affect other databases that aren't being tracked by PITR. At the very least we should add rail guards to error out if the user wants to restore in such scenarios. cc @spolitov @bmatican

[vkulichenko]

I don't think it's a good idea to error out the restore. This can lead to a scenario when a user makes a change in a global object (i.e., drops a tablespace), then tries after some time accidentally drops an unrelated table, but can't restore it because PITR doesn't work anymore.

Instead, we should error out the operations that potentially break PITR, like dropping a tablespace or a role. Are there any other operations like that @sanketkedia?

[lingamsandeep]

Global objects will not be restored. These are user's responsibility.