Adding table properties to signal replication run state

[rohitkum2506]

Summary

Adding a property in tblProperties to indicate replication run state for a table based on replicationConfig addition/update.
Property: replication.enableSetup
Cases:

1. Table Created without replication Policy -> Replication.enableSetup is not added.
2. Table Created with replication Policy -> Replication.enableSetup is added. Values is set to true
3. Table is updated with a new value for replication policy -> Replication.enableSetup is added. Value is set to true
4. Table is updated without changes to replication policy - > No changes to replication.enableSetup property

Based on boolean value of the property, replication job is triggered only when needed, ie. when policy is added or updated.

Changes

• Client-facing API Changes
• Internal API Changes
• Bug Fixes
• New Features
• Performance Improvements
• Code Style
• Refactoring
• Documentation
• Tests

For all the boxes checked, please include additional details of the changes made in this pull request.

Testing Done

Unit tests added.
Local Docker system tests:
1: Created table without replication config -> Observed tblProperty is not set
2. Created table without replication config -> tblProperty is set to true
3. Updated tblProperty to false
4. Updated replication config -> tblProperty Replication.enableSetup was set to true
5. Added other table policies -> no effect on tblProperty Replication.enableSetup

• Manually Tested on local docker setup. Please include commands ran, and their output.
• Added new tests for the changes made.
• Updated existing tests to reflect the changes made.
• No tests added or updated. Please explain why. If unsure, please feel free to ask for help.
• Some other form of testing like staging or soak time in production. Please explain.

For all the boxes checked, include a detailed description of the testing done for the changes made in this pull request.

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.

For all the boxes checked, include additional details of the changes made in this pull request.

[autumnust]

I believe this is a leakage of implementation details to expose such internal state as table properties, not to mention the table table properties itself can be lost / modified by users directly. We can certainly make this a preserved key to defend against that argument, but I believe this is the wrong step to start to begin with.

Let's iterate on slack about what is the problem trying to solve here and understand that better.