feat: migrate from Cedar to SpiceDB authorization system

This is a major architectural change that replaces the Cedar policy-based
authorization system with SpiceDB's relation-based authorization.

Key changes:

- Migrate from Rust to Go implementation
- Replace Cedar policies with SpiceDB schema and relationships
- Switch from envoy `ext_authz` with Cedar to SpiceDB permission checks
- Update build system and dependencies for Go ecosystem
- Maintain Envoy integration for external authorization

This change enables more flexible permission modeling through SpiceDB's
Google Zanzibar inspired relation-based system, supporting complex
hierarchical permissions that were difficult to express in Cedar.

Breaking change: Existing Cedar policies and Rust-based configuration
will no longer work and need to be migrated to SpiceDB schema.

1 files changed, 0 insertions, 40 deletions

diff --git a/vendor/android_system_properties/CONTRIBUTING.md b/vendor/android_system_properties/CONTRIBUTING.md
deleted file mode 100644
index 62436f59..00000000
--- a/vendor/android_system_properties/CONTRIBUTING.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Contributing
-
-Contributions are very much welcome. Here are the guidelines if you are thinking of helping us:
-
-## Contributions
-
-Contributions should be made in the form of GitHub pull requests.
-Each pull request will be reviewed by a core contributor (someone with
-permission to land patches) and either landed in the main tree or
-given feedback for changes that would be required.
-
-Should you wish to work on an issue, please claim it first by commenting on
-the GitHub issue that you want to work on it. This is to prevent duplicated
-efforts from contributors on the same issue.
-
-## Pull Request Checklist
-
-- Branch from the master branch and, if needed, rebase to the current master
-  branch before submitting your pull request. If it doesn't merge cleanly with
-  master you may be asked to rebase your changes.
-
-- Commits should be as small as possible, while ensuring that each commit is
-  correct independently (i.e., each commit should compile and pass tests).
-
-- If your patch is not getting reviewed or you need a specific person to review
-  it, you can @-reply a reviewer asking for a review in the pull request or a
-  comment.
-
-- Whenever applicable, add tests relevant to the fixed bug or new feature.
-
-For specific git instructions, see [GitHub workflow 101](https://github.com/servo/servo/wiki/Github-workflow).
-
-## Conduct
-
-We follow the [Rust Code of Conduct](http://www.rust-lang.org/conduct.html).
-For escalation or moderation issues, please contact Nical (nical@fastmail.com) instead of the Rust moderation team.
-
-## License
-
-Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be licensed dual MIT/Apache 2, without any additional terms or conditions.