CP/DP Split: Remove NGINX manager and deployment

[sjberman]

Removing the nginx runtime manager and deployment container since nginx will live in its own pod managed by agent. Temporarily saving the nginx deployment and service for future use.

Updated the control plane liveness probe to return true once it's processed all resources, instead of after it's written config to nginx (since nginx may not be started yet in the future architecture).

Testing: Verified that the control plane is able to start and run on its own.

Closes #2838

[codecov]

Codecov Report

Attention: Patch coverage is 30.61224% with 34 lines in your changes missing coverage. Please review.

Project coverage is 90.32%. Comparing base (6ab4a5d) to head (09b399d).

Files with missing lines	Patch %	Lines
internal/mode/static/manager.go	0.00%	25 Missing ⚠️
internal/mode/static/nginx/agent/agent.go	0.00%	7 Missing ⚠️
internal/mode/static/handler.go	81.81%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@                         Coverage Diff                         @@
##           change/control-data-plane-split    #2936      +/-   ##
===================================================================
+ Coverage                            89.74%   90.32%   +0.57%     
===================================================================
  Files                                  109      103       -6     
  Lines                                11150    10708     -442     
  Branches                                50       50              
===================================================================
- Hits                                 10007     9672     -335     
+ Misses                                1083      984      -99     
+ Partials                                60       52       -8     

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

[kate-osborn]

See my review for a small nit, but otherwise LGTM

[salonichf5]

It would be more idiomatic to rename this Write as per the Go guidelines that i was going through, unless there is another reason it is named WriteFile

The importer of a package will use the name to refer to its contents, so exported names in the package can use that fact to avoid repetition. (Don't use the import . notation, which can simplify tests that must run outside the package they are testing, but should otherwise be avoided.) For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader. Similarly, the function to make new instances of ring.Ring—which is the definition of a constructor in Go—would normally be called NewRing, but since Ring is the only type exported by the package, and since the package is called ring, it's called just New, which clients of the package see as ring.New. Use the package structure to help you choose good names.

[salonichf5]

nit: I see comments in various places using we've or we are ready. Do you think it would be better to use control plane or NGINX Gateway Fabric to be clearer for future readers?