Fix VReplication logging to file and db

[rohit-nayak-ps]

Description

• Errors like duplicate key errors while bulk inserting during the copy phase can generate huge log lines. Since we also write to _vt.vreplication_log that table also gets filled up fast since we keep retrying within vreplication. This PR truncates the logs both in the file logs and in the _vt.vreplication_log table
• The logic for updating count of recurring errors in _vt.vreplication_log was not working because the controller would set the state of the restarted workflow again, which was getting logged to _vt.vreplication_log alternating with the actual error. This has been fixed by ignoring this spurious state change log
• Some unnecessary/repetitive log lines have been removed

Aside

One reason why log files were filling up is that we retry the workflow on error every 5 seconds, by default. The reason we retry is that transient errors like network failures or server restarts may occur and we don't want the vreplication workflow to error out permanently but keep retrying. We may want to increase this default since, in general, most such situations appear to be non-recoverable and the user needs to intervene to fix it. This needs more discussion though.

For now users can setup -vreplication_retry_delay to change this.

Checklist

• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

[deepthi]

LGTM