Remove swatch-contracts PUT/update logic

4/17 updates - we don't have a reason to update contracts...so we're removing this endpoint

Cloned from the original Jira card.  There was a disconnect between what was implemented vs what the expected behavior of the Update contracts API was.  This card is for tracking adjustments to the API after collaboration with rhimmelw 

• If you try to update product_id, subscription_number, or start_date via the PUT api, don't actually update the contract - instead create a new contract record but bbe sure to log a warning about what's happening.  It allows QE to do "weird" testing.  We're not looking for air-tight API implementations here, but for facilating testing of unlikely but edge case scenarios.

Original card description:

Make sure the update functionality of the get contracts and update contract test APIs.  An org either has an active contract for a subscription or they don't.  We want our logic to mirror what the entitlement gateway considers "new contracts".  If the entitlement gateway receives an update on their "purchase" object, the entry at purchase.contract[?].endDate === undefined gets updated to purchase.contract[?].endDate = date.now, and then a new entry gets added to the purchase.contracts array - with a startDate = date.now, and endDate = undefined.  We want our logic to behave similarly.

• If anything changes within Set<ContractMetric>,  this should create new Contract/ContractMetrics records in the database.
• The old Contract record will have its end_date updated to OffsetDateTime.now()
• The old Contract record should be cloned, and become a new Contract record.
• The new Contract record should get a new UUID.randomUuid() as its id
• The new Contract record should get startDate of OffsetDateTime.now()
• The new Contract record should get an endDate of null
• If PUT is called but a change to product_id is in the payload, this should warn/error in the logs that a new Contract is being created rather than "updated".  Programmatically this should be treated identically with a new Contract/ContractMetric record being created with its own uuid.

Be sure to update the openapi spec to explain that "f there is increase in instance-hours it will be a new uuid and the previous contract will have end date as today's date. The new uuid will have end date as null. we're also saying is that when you CREATE a new contract, we're going to force end_date to be null.  even if someone tries to set it in the payload"

Discussed during dev sync 2/27 https://docs.google.com/document/d/16bGEilEsp2nW2vVK2p9GEXdGOQyjvfOxpOtaN6Nfydg/edit