Improve TAA acceptance date validation

Story
As a developer building solutions for a network that enforces a Transaction Author Agreement, I want my organization's legal team to be able to review and accept the TAA in advance of it being written to the ledger. Thus when we submit a transaction we can report the real date of meaningful acceptance, instead of an arbitrary date engineered to be newer than when the TAA is added. This will also allow us to stage the configuration change in advance of the TAA being added, which reduces our risk of disruption when the TAA is written.

The TAA could be legally accepted at any point after the TAA is approved by network governance. After approval, it takes some time for the TAA to be encoded in MarkDown and anchored on the ledger.

Validating that the date of TAA acceptance is after the TAA was written to the ledger causes organizations that accepted the TAA in advance to risk a disruption to the ability to write to the ledger because they can't finalize their configuration until after the date the TAA is added to the ledger. They should be able to deploy the configuration change earlier so that it is ready when the ledger is updated, and indicate a more accurate date of TAA acceptance.

Acceptance Criteria

• When a TAA is anchored to the ledger, it must include a property representing the date when the TAA was approved for use on the network. Let's call it taa_ratified_date.
• The taa_ratified_date must be in the past.
• The taa_ratified_date cannot be edited by the administrator.
• If a TAA is already on the ledger, then the date the transaction was written to the ledger should be used as the taa_ratified_date.
• When a TAA is enforced on a ledger, accept any date for the TAA acceptance that is equal to or earlier than the present time and newer than or equal to the ratified_date (preserving the current logic to account for a few minutes of clock skew).
• Update the documentation.

Notes

• The taa_ratified_date must be in the past to avoid the challenges that come with the latest TAA being invalid, or dynamically updating the value with the proper BLS signatures when it becomes valid.
• The taa_ratified_date cannot be modified in order to simplify development and testing (changing requirements are threatening to delay the release). If we need to be able to modify it, we can scope that as a separate story.
• Reason for the change:
  • When we originally designed the TAA, we thought it would be important to validate that the date of TAA acceptance was realistic. We considered this important for the TAA acceptance to fulfill its role as evidence of meaningful acceptance.
  • However, we erroneously had a mental model of individuals interacting with the ledger in real-time, whereas individual data should not be written to the public ledger so the majority of writes are made by organizations where the software operator is not authorized to bind the organizations to an agreement like the TAA. That must be done by the legal team and management.
  • Further, we did not consider that there will be a lag between the TAA being published, and when it will actually be put on the ledger. In reality, the date of acceptance can predate the enforcement on the ledger.
  • Finally, we did not appreciate the coordination difficulty caused by having to coordinate the date of TAA acceptance. We don't want to require every client to have to code around the problem.