[LETS-483] [LETS-495] initialize mvcc table on pts

[cristiarg]

http://jira.cubrid.org/browse/LETS-483 http://jira.cubrid.org/browse/LETS-495

Correctly initialize mvcc table on passive transaction server:

• when PTS starts, it receives boot information from the page server (PS)
• this info will contain the LSA of the most recent transaction table snapshot and log_Gl.hdr.append_lsa from page server (which is the LSA up to which PS is able to return transactional log pages)
• PTS then proceeds to initialization a valid mvcc table
• it first loads the transactions from the snapshot into the transaction table
• with the information up to this point (the transaction table snapshot point, as it were), it reconstructs a correct MVCC table
• afterwards, it continues by analysing the log up to the point specified by the value of log_Gl.hdr.append_lsa received from PS
• while analysing the log, it will maintain MVCC information in the transaction table and, when encountering transaction commits or aborts, it will also complete present mvccid's accordingly
• after finishing log analysis, the MVCC table is in a state consistent to be picked up by the - soon to be started - transactional log replication

Implementation:

• log_initialize_passive_tran_server
  • pass replication_start_redo_lsa to log_recovery_analysis_from_trantable_snapshot to allow log_recovery_analysis to know when to stop analysing the log
  • remove call to logtb_define_trantable_log_latch which, after log recovery analysis, will incorrectly reset an already initialized transaction table and the already initialized MVCC table
• log_recovery_analysis_from_trantable_snapshot:
  • do log_recovery_build_mvcc_table_from_trantable right after constructing the transaction table out of the information in transaction table snapshot; this will provide a basis for log recovery analysis to process log records and maintain&update the MVCC information
  • call log_recovery_analysis_internal but request to stop before the LSA at which point log replication will take over
• log_recovery_build_mvcc_table_from_trantable: also receives the parameters replicated_mvcc_next_id with which, in the absence of any active transactions in the transaction table snapshot (and, consequently, in the recovered transaction table), it will initialize the MVCC table by setting log_Gl.hdr.mvcc_next_id and initializing the MVCC table (log_Gl.mvcc_table.reset_start_mvccid)
• log_recovery_analysis_internal:
  • separated new internal function which takes extra parameters: reset_mvcc_table whether to [re]initialize or not the MVCC table; stop_before_lsa which - if present - specifies the LSA before which the analysis should stop (this should only be the case for passive transaction server initialization as the same function is used for monolithic server recovery after a crash)
• mvcctable::complete_mvcc: added an assert that, mvccid's which are completed during passive transaction server's initialization do not re-appear later during replication (extensive comment in code with details)