feat: Add remote materialization support via feature server

[aniketpalu]

What this PR does / why we need it:

Allow store.materialize() and materialize_incremental() to delegate execution to the feature server instead of running the batch engine locally. This eliminates the need for engine-specific dependencies (PySpark, kubernetes client, etc.) and RBAC on the client pod. Components:

• New shared poll_materialization_status() function
• Client-side _remote_materialize() with registry-based FV state polling
• POST /materialize-async and /materialize-incremental-async endpoints (202)
• materialize_mode, url, timeout, poll_interval config fields
• 19 unit tests + 2 E2E integration tests Addresses Remote materialization #4526 (remote materialization).

Which issue(s) this PR fixes:

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests
• Manual tests
• Testing is not required for this change

Misc

[jyejare]

I think we dont need to provide the materialize_mode config. We should strictly feature server take care of materialization delegation to compute engine. Leaving no choice to do materialization on client side.

[ntkathole]

A cleaner approach might be: a RemoteComputeEngine (like RemoteOnlineStore/RemoteOfflineStore) that POSTs to the existing /materialize endpoint, returning a job handle with a dedicated /materialize-status/{job_id} endpoint - keeping the materialization delegation at the engine layer rather than the FeatureStore layer.

[aniketpalu]

if you mean something like

batch_engine:
  type: remote.engine
  path: https://feast-online:443   # same host as online
  cert: /var/run/secrets/.../service-ca.crt

I thought about this before choosing current approach. I see two points which made me not take this decision.

1. This adds another config section which has to indicate only one thing, i.e. trigger materialization on feature server. For this, it add 1 config section & user has to configure 2 redundant fields.
2. Once client is initialized, user wont have option to try normal materialization flow if remote materialization fails for any reason.

My proposed approach is

store.materialize(remote=True, wait=False) --> pre-process check & return 202 Accepted response
store.poll_materialization() --> returns status

This approach has

1. Backward compatibility - User can fall back without re-initializing client.
2. Flexibility of Status polling - Full control to user to set interval of polling.
3. No need of Operator changes.
4. The same API can work for UI as well

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 75.11521% with 54 lines in your changes missing coverage. Please review.
✅ Project coverage is 45.78%. Comparing base (dcd496f) to head (c1f53c9).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
sdk/python/feast/feature_store.py	63.15%	31 Missing and 4 partials ⚠️
sdk/python/feast/feature_server.py	82.19%	12 Missing and 1 partial ⚠️
sdk/python/feast/infra/registry/snowflake.py	0.00%	3 Missing ⚠️
sdk/python/feast/infra/registry/sql.py	0.00%	3 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6590      +/-   ##
==========================================
- Coverage   46.00%   45.78%   -0.22%     
==========================================
  Files         406      413       +7     
  Lines       48164    48974     +810     
  Branches     6814     6950     +136     
==========================================
+ Hits        22157    22425     +268     
- Misses      24461    25000     +539     
- Partials     1546     1549       +3     

Flag	Coverage Δ
go-feature-server	30.58% <ø> (ø)
python-unit	47.07% <75.11%> (-0.26%)	⬇️

Files with missing lines	Coverage Δ
sdk/python/feast/feature_view.py	85.71% <ø> (ø)
sdk/python/feast/materialization_status.py	100.00% <100.00%> (ø)
sdk/python/feast/infra/registry/snowflake.py	39.35% <0.00%> (-0.22%)	⬇️
sdk/python/feast/infra/registry/sql.py	57.70% <0.00%> (-0.26%)	⬇️
sdk/python/feast/feature_server.py	65.43% <82.19%> (+2.59%)	⬆️
sdk/python/feast/feature_store.py	42.62% <63.15%> (+1.56%)	⬆️

... and 10 files with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dcd496f...c1f53c9. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.