Add "Deleting" phase for restore display

[allenxu404]

Thank you for contributing to Velero!

Please add a summary of your change

Does your change fix a particular issue?

Fixes #6582

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file or added /kind changelog-not-required as a comment on this pull request.
• Updated the corresponding documentation in site/content/docs/main.

[allenxu404]

/kind changelog-not-required

[allenxu404]

/kind changelog-not-required

[codecov-commenter]

Codecov Report

Merging #6604 (cc03b7a) into main (d027a16) will decrease coverage by 0.03%.
Report is 5 commits behind head on main.
The diff coverage is 11.11%.

@@            Coverage Diff             @@
##             main    #6604      +/-   ##
==========================================
- Coverage   60.18%   60.15%   -0.03%     
==========================================
  Files         242      242              
  Lines       25654    25667      +13     
==========================================
+ Hits        15439    15440       +1     
- Misses       9139     9150      +11     
- Partials     1076     1077       +1     

Files Changed	Coverage Δ
pkg/cmd/util/output/restore_describer.go	32.17% <0.00%> (-0.57%)	⬇️
pkg/cmd/cli/restore/get.go	72.09% <25.00%> (-4.84%)	⬇️

... and 1 file with indirect coverage changes

[ywk253100]

This will cause inconsistent between the Velero and kubectl when getting the restores, @sseago is there any way to specify the status in CRD according to different conditions?

[sseago]

@ywk253100 I don't think we have an issue here. kubectl doesn't show status information for restores, unlike velero CLI:

$ kubectl get restore -n openshift-adp
NAME                           AGE
mysql-datamover4-1             9d
mysql-datamover5-1             9d
mysql-datamover5-2             9d

[sseago]

And if you're looking at yaml, then you want to see the real Phase value, but again the deletion timestamp tells you it's terminating. As long as the velero CLI summary shows deleting/terminating and any code that differs for terminating restores checks deletion timestamp, this should be good.

[sseago]

You probably want to check deletion timestamp on the logs command, as was covered in the original change-phase PR:

https://github.com/vmware-tanzu/velero/pull/6599/files#diff-aa4ed12cfdf5527ebf5441e9ea40d8cb40f9f4d446a5742d12e48e6bd281189e