fix: sync default appproject updates to managed agents

[chetan-rns]

What does this PR do / why we need it:
The principal should propagate default AppProject updates to the managed agents. This PR handles several issues:

• The user could have already created the default AppProject before running the agent. The agent should remove the user-created default AppProject and create the default AppProject from the principal. It should add the source UID annotation.
• The default AppProject may only have the destination server field and not the name. The principal should consider both the name and the server to match the agent. Since the principal doesn't know the workload cluster's server, we only check if the server is a wildcard.
• Add support for deny patterns
• Add e2e tests to verify the behavior

Which issue(s) this PR fixes:

Fixes #509

How to test changes / Special notes to the reviewer:

Checklist

• Documentation update is required by this PR (and has been updated) OR no documentation update is required.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 68.57143% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 45.19%. Comparing base (8ed7e84) to head (2b021b5).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
principal/callbacks.go	71.18%	14 Missing and 3 partials ⚠️
agent/agent.go	0.00%	4 Missing ⚠️
internal/resync/resync.go	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #529      +/-   ##
==========================================
+ Coverage   45.10%   45.19%   +0.08%     
==========================================
  Files          88       88              
  Lines       10945    10992      +47     
==========================================
+ Hits         4937     4968      +31     
- Misses       5618     5631      +13     
- Partials      390      393       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[chetan-rns]

Looking at the argo-cd code, it checks for both the destination name and the server, and either one of them should match. But the principal isn't aware of the workload cluster's server URL, and the cluster secret points to the resource proxy. So, if the user doesn't want to use the name, the only option is to use a wildcard for the server. i.e, we match the agent if the server is * even if the name doesn't match. WDYT?

I guess we could pass the workload cluster URL to the principal in the client context. But so far, the principal doesn't know about the workload cluster, and the agent is the only point of contact.

[jannfis]

and either one of them should match

Either one should match or be empty. Setting both fields as destination at the same time is imho not supported by Argo CD, i.e. you need to set either name or server, but not both.

the cluster secret points to the resource proxy

The cluster secret points to a specific URL including the agent-name in the query param, so a user could match it. However, I think it would be fair to force the user to use the name of the agent instead of the server URL for now. The URLs will all look similar, except for the suffix, anyway.

[chetan-rns]

Thanks! I've updated the logic to compare the agent name from the server URL query param. The server URL check is required for the default AppProject, which doesn't have the destination name set initially. The function will only compare the server if the name is not provided.

[jannfis]

@chetan-rns The merge of #526 introduced some conflicts that need to be resolved.