Refactor/attempts number and logs

[ruionweb]

What are you trying to accomplish with this PR?
This change allows for some context deadline errors to be retried addressing issue
https://github.com/Shopify/shipit/issues/1227
How is this accomplished?

We noticed that many of the context deadline errors came from cmd:get, we've
updated the number of attempts on the following functions:

• validate_context_exists_in_kubeconfig (cmd: config, get-context)
• version_info (cmd: version)
• validate_context_reachable (cmd: get, namespace)
• validate_namespace_exists (cmd: get, namespace)

Before you deploy

• I tophatted or tested this change.
• This PR is safe to rollback.

[timothysmith0609]

I imagine a lot of the timeouts will occur while syncing resources waiting for convergence. I notice you haven't added retries there. Is that on purpose or an oversight?

[ruionweb]

My line of thought was that both the TaskConfigValidator and kubectl version_info gets called during the "Initializing deploy" phase of the deploy task:

TaskConfigValidator: https://github.com/Shopify/krane/blob/master/lib/krane/deploy_task.rb#L141

Version_info (via validate_definition): https://github.com/Shopify/krane/blob/master/lib/krane/deploy_task.rb#L143

To my understanding it is Resource Watcher that runs sync_resources, and at this point, there are no Resource watchers created for the Kubernetes resources until the "Predeploy priority resources" phase.

https://github.com/Shopify/krane/blob/master/lib/krane/deploy_task.rb#L150

Other areas where TaskConfigValidator is called is in the restart task and run task during verify_config, which are commands separate from the Krane deploy

Please let me know what you think! @timothysmith0609 🙂