kubernetes: Human readable duration formats exact year inconsistently

What happened: When the duration is exactly 2 years or 3 years, human readable duration is returned as 2y0d or 3y0d. But when the duration is exactly 4 years, 5 years, etc, the human readable duration is returned as 4y, 5y, etc.

What you expected to happen: The format of an exact year should be consistent. Remove 0d when duration is an exact year:

• 2y0d should be 2y
• 3y0d should be 3y
• Check other years… 4, 5, 6, 7… not sure if they also have the problem.

How to reproduce it (as minimally and precisely as possible): Because this is time-dependent, it can be difficult to reproduce via the CLI, but you can see the problem illustrated in this unit test which shows the current behavior:

		{d: 2 * 365 * 24 * time.Hour, want: "2y0d"},
		{d: 2*365*24*time.Hour + 23*time.Hour, want: "2y0d"},
		{d: 3 * 365 * 24 * time.Hour, want: "3y0d"},
		{d: 8*365*24*time.Hour - time.Millisecond, want: "7y364d"},
		{d: 8 * 365 * 24 * time.Hour, want: "8y"},
		{d: 8*365*24*time.Hour + 364*24*time.Hour, want: "8y"},
		{d: 9 * 365 * 24 * time.Hour, want: "9y"},

The 2y0d and 3y0d test cases should be changed to want 2y and 3y, and the code should be changed to make that pass.

Anything else we need to know?: Note, this is not a problem when the duration is exactly 1 year because the human readable duration is still shown in days. So nothing needs to change to handle the case of exactly 1 year.

Environment:

• Kubernetes version (use kubectl version): 1.18
• Cloud provider or hardware configuration: n/a
• OS (e.g: cat /etc/os-release): n/a
• Kernel (e.g. uname -a): n/a
• Install tools: n/a
• Network plugin and version (if this is a network-related bug): n/a
• Others: n/a