refactor: split data plane module into two separate modules

[hamidonos]

What this PR changes/adds

• Split data-plane-api module into two separate modules data-plane-control-api & data-plane-public-api
• Map data-plane-public-api module to public-api group

Why it does that

Interfaces under data-plane-public-api should not be under control-api api group because this api group is intended for internal communication.

Further notes

This introduces a breaking change because the data-plane-api module has been split into data-plane-control-api and data-plane-public-api. Downstream projects need to adjust their dependencies.

Note that the migration of the data-plane-api README file will be handled in a separate PR.

Linked Issue(s)

Closes #3373
Depends on #3686

[codecov-commenter]

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (bdd6a2a) 71.73% compared to head (b1da7d9) 71.72%.

Files	Patch %	Lines
...or/dataplane/api/DataPlaneControlApiExtension.java	0.00%	4 Missing ⚠️
.../api/controller/DataPlaneControlApiController.java	66.66%	2 Missing ⚠️
...tor/dataplane/api/DataPlanePublicApiExtension.java	0.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3676      +/-   ##
==========================================
- Coverage   71.73%   71.72%   -0.02%     
==========================================
  Files         919      919              
  Lines       18465    18468       +3     
  Branches     1034     1034              
==========================================
  Hits        13246    13246              
- Misses       4760     4763       +3     
  Partials      459      459              

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

[jimmarino]

Can we please break this into two PRs because the module shift has implications for downstream repositories and is not a "doc" change?

[hamidonos]

Can we please break this into two PRs because the module shift has implications for downstream repositories and is not a "doc" change?

The creation of the new public hub & split of the modules is the minimum requirement for this PR
If we split the "doc" part into a separate PR then we will release two modules (this PR) with wrong/missing doc
To me the modularization + doc change is one unit

[jimmarino]

Can we please break this into two PRs because the module shift has implications for downstream repositories and is not a "doc" change?

The creation of the new public hub & split of the modules is the minimum requirement for this PR If we split the "doc" part into a separate PR then we will release two modules (this PR) with wrong/missing doc To me the modularization + doc change is one unit

We are not releasing the doc at this point. The two changes are distinct, particularly because the module split has significant downstream implications. Please make these changes in two separate PRs so that they can be reviewed and documented correctly.

[ndr-brt]

LGTM

[jimmarino]

This PR does not appear to break out the changes into two PRs as requested (at least the title does not indicate that, and my issue was not marked as resolved).

Please put the module refactor in its own PR.

[hamidonos]

This PR does not appear to break out the changes into two PRs as requested (at least the title does not indicate that, and my issue was not marked as resolved).

Please put the module refactor in its own PR.

This PR is now solely responsible for the module migration

I'm unable to resolve your comment tho