Cleanup development feature flags for locking namespaces fix

What does this MR do and why?

Cleanup feature flags sync_traversal_ids_before_commit, for_no_key_update_lock related to fixing the namespace locking issues.

I've taken the path of moving from FFs default off to removing the FF based on documentation https://docs.gitlab.com/ee/development/feature_flags/index.html#changelog

NOTE: the for_no_key_update_lock FF was enabled on staging and production on 25th Feb.

Logs since 2022-02-21

• Staging

  • Create project REST calls: ~30K, https://nonprod-log.gitlab.net/goto/21bded40-993e-11ec-b3a6-472d0398dd6e
  • Requests with locking issues: 0, https://nonprod-log.gitlab.net/goto/b068c100-993e-11ec-b3a6-472d0398dd6e

• Production

  • Create project REST calls: ~70K, https://log.gprd.gitlab.net/goto/6c7c99d0-993e-11ec-a649-b7cbb8e4f62e
  • Requests with locking issues: 26, all related to gitlab-qa, https://log.gprd.gitlab.net/goto/c9b16130-993e-11ec-a649-b7cbb8e4f62e
  • Create project REST calls by gitlab-qa: 24K, https://log.gprd.gitlab.net/goto/e40aae10-993e-11ec-9dd2-93d354bef8e7

Note that we expect to see some locking timeouts, we cannot completely exclude those as it depends on the duration the lock is held and the number of concurrent traversal_ids being updated for same hierarchy. However the number of locks timeouts we are seeing is a very low percentage.

• re #351323 (closed)
• re #352499 (closed)
• re #353619 (closed)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.