Allow users to delete AppNamespace

[klboke]

What's the purpose of this PR

Consistent with user deletion of Namespace and administrator deletion of AppNamespace

• reference：Questions about deleting private Namespace #4485

[codecov-commenter]

Codecov Report

Merging #4499 (4696f13) into master (4ca9739) will decrease coverage by 0.01%.
The diff coverage is 65.00%.

@@             Coverage Diff              @@
##             master    #4499      +/-   ##
============================================
- Coverage     53.46%   53.45%   -0.02%     
- Complexity     2703     2704       +1     
============================================
  Files           490      491       +1     
  Lines         15347    15395      +48     
  Branches       1598     1599       +1     
============================================
+ Hits           8205     8229      +24     
- Misses         6585     6607      +22     
- Partials        557      559       +2     

Impacted Files	Coverage Δ
.../apollo/portal/controller/NamespaceController.java	11.82% <0.00%> (-0.40%)	⬇️
...ork/apollo/portal/service/AppNamespaceService.java	66.00% <ø> (ø)
...mework/apollo/portal/entity/vo/NamespaceUsage.java	51.72% <51.72%> (ø)
...mework/apollo/portal/service/NamespaceService.java	72.39% <85.71%> (+0.80%)	⬆️
...work/apollo/biz/message/DatabaseMessageSender.java	56.25% <0.00%> (-8.34%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[nobodyiam]

For public and private namespaces, I think we still need to check the instances bycheckMasterInstance and checkBranchInstance?

[klboke]

• Here it is considered that the user delete action is expected.
• Only the current environment and the usage of the current cluster can be checked here, and deleting the AppNamespace will affect all clusters, so the logic here remains consistent with the administrator's deletion
• Or, is there a need to check the usage of all clusters in all environments?

[nobodyiam]

In this case, there is a detailed message indicating that this operation will cause the instances unable to get the configuration, so I think it's ok to not checkMasterInstance and checkBranchInstance.
If we don't check for public and private namespaces, I suppose we don't need to check for linked namespaces?

[klboke]

If we don't check for public and private namespaces, I suppose we don't need to check for linked namespaces?

Yes, I think they are the same type of problem

[nobodyiam]

So maybe we could simplify the logic as the following?

                //1. check operator has master permission
                checkPermission(toDeleteNamespace).then(function () {

                    if (!toDeleteNamespace.isPublic || toDeleteNamespace.isLinkedNamespace) {
                        showDeleteNamespaceConfirmDialog();
                    } else {
                        //2. check public namespace has not associated namespace
                        checkPublicNamespace(toDeleteNamespace).then(function () {
                            showDeleteNamespaceConfirmDialog();
                        });
                    }
                })

[klboke]

The logic for deleting different types of Namespace on the user side has been unified, and a uniform instance usage prompt message is added before deletion, e.g.

• Delete private Namespace

• Delete public Namespace

• Delete linked Namespace

[nobodyiam]

It looks great! Please find some comments below.

[nobodyiam]

LGTM