doc: add design proposal for multi-tenancy simplification

[hyunsun]

Description

Add design proposal for multi-tenancy simplification.

Fixes # (issue)

Any Newly Introduced Dependencies

Please describe any newly introduced 3rd party dependencies in this change. List their name, license information and how they are used in the project.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

• I agree to use the APACHE-2.0 license for my code changes
• I have not introduced any 3rd party dependency changes
• I have performed a self-review of my code

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Make a comment or update the PR to avoid closing PR after 15 days.

[scottmbaker]

LGTM, and this will be a significant improvement and simplification, especially as services are decomposed. A secondary benefit is that it will make it more feasible for developers to work on services in isolation, and reduce resource requirements for development.

Two high level comments:

1. Would be good to have more specificity on Step 3: Tenant Manager Modernization. The current implementation leverages Nexus as the backend implementation of that model. Are we continuing to use Nexus as the backend for 2026.0? The individual services tenant controllers watch CRDs that were managed by Nexus. The deeper we go with refactoring the multitenant implementation, the more the changes may propagate to the tenant controllers.
2. For 'Tract 2: Make Multi-Tenancy Configurable". Some tenant controllers may be responsible for upgrade functionality. For example, the AppOrch Tenant Controller is responsible for loading new extension deployment packages. We will need to understand how this upgrade process changes in Track 2, if it needs to change at all.