…fix UserDTO audit validation (#11115)

### What changes were proposed in this pull request?

- Add audit null validation in `UserDTO.Builder.build()` to align with
the Java side
- Add integration tests for User API (`add_user`, `get_user`,
`remove_user`, `list_users`, `list_user_names`)
- Update existing unit tests to provide audit in Builder calls

### Why are the changes needed?

The Java `UserDTO.Builder.build()` validates `audit != null`, but the
Python counterpart does not. Also, PR #11058 only added mocked unit
tests for the User API. Integration tests are needed to validate against
a real Gravitino server.

Fix: #11114

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

- 8 new integration tests passed against a real Gravitino server with
authorization enabled
- 36 existing unit tests passed

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

)

## Summary
This PR adds Group authorization management support to the Gravitino
Python client SDK, following the pattern established in #11058 (User
management). It is split from the original monolithic PR #10783.

### Changes
- **API**: `Group` interface with `name()` and `roles()` methods
- **DTO**: `GroupDTO` with immutable roles (`tuple[str, ...]`
internally, defensive `list` copy via `roles()`); audit null validation
in Builder
- **Request/Response**: `GroupAddRequest`, `GroupResponse`,
`GroupListResponse`, `GroupNamesListResponse`
- **Error Handler**: `GroupErrorHandler` mapping REST error codes to
`NoSuchGroupException`, `GroupAlreadyExistsException`, etc.
- **Client**: 5 CRUD methods on both `GravitinoMetalake` and
`GravitinoClient` (`add_group`, `remove_group`, `get_group`,
`list_groups`, `list_group_names`)
- **Tests**: Unit tests (33 cases) and integration tests (6 cases)

### Sub-task of
- #10782 (Authorization management for Python SDK)

## Related issues
- Closes #11094

## Reviewers
@jerryshao

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>

…ructures (#11210)

### What changes were proposed in this pull request?

Add Role CRUD operations and authorization data structures to the Python
client SDK:

- **DTOs**: `PrivilegeDTO`, `SecurableObjectDTO`, `RoleDTO` with JSON
serialization support
- **Role CRUD**: `create_role`, `get_role`, `delete_role`,
`list_role_names` on `GravitinoMetalake` and `GravitinoClient`
- **DTOConverters**: `to/from_privilege_dto` and
`to/from_securable_object_dto` conversion methods
- **Fix**: `GenericPrivilege.__eq__` now checks `isinstance(value,
Privilege)` for `PrivilegeDTO` compatibility
- **Tests**: Unit tests (DTO, response, client delegate, error handler)
and integration tests against a live server

### Why are the changes needed?

This is the Role authorization piece of issue #10782. User (#11058) and
Group (#11094) management are already merged. Role CRUD is a
prerequisite for Grant/Revoke operations, which will follow in a
separate PR.

Fix: #11095

### Does this PR introduce _any_ user-facing change?

Yes — new public APIs on `GravitinoClient` and `GravitinoMetalake`:
- `create_role(role_name, properties=None, securable_objects=None)`
- `get_role(role_name)`
- `delete_role(role_name) -> bool`
- `list_role_names() -> list[str]`

### How was this patch tested?

- Unit tests: all passed
- Integration tests: 4 passed against a live Gravitino server with
authorization enabled
- Linting: `ruff check` clean, `pylint` 10/10

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>

…apache#11058)

### What changes were proposed in this pull request?

This PR is split from apache#10783 to make review easier. It focuses on the
**User** part of the authorization model; Group, Role, Privilege,
SecurableObject and grant/revoke operations will follow in subsequent
PRs.

Changes in this PR:

1. **API layer** (`gravitino/api/authorization/`)
   - `User` — user interface with `name()` / `roles()` accessors

2. **DTO layer** (`gravitino/dto/authorization/`)
   - `UserDTO` — immutable DTO with builder pattern, serialization
     and audit info

3. **Request / Response DTOs** (`gravitino/dto/`)
   - `UserAddRequest`
   - `UserResponse` / `UserListResponse` / `UserNamesListResponse`
   - `RemoveResponse` (shared boolean-remove response used across
     authorization operations)

4. **Client layer** (`gravitino/client/gravitino_metalake.py`)
   - Five new public methods on `GravitinoMetalake`:
     `add_user` / `get_user` / `remove_user` / `list_users` /
     `list_user_names`

5. **Exception handling** (`gravitino/exceptions/`)
   - `NoSuchUserException`, `UserAlreadyExistsException`
   - `UserErrorHandler` mapping REST error codes to the above

### Why are the changes needed?

The Python SDK currently has no authorization management capabilities,
while the Java SDK and REST API have full support. This PR starts
bringing the Python SDK to feature parity with the Java SDK, beginning
with User management as the most foundational entity.

Fix: apache#11098

### Does this PR introduce _any_ user-facing change?

Yes. New public API:
- `GravitinoMetalake.add_user(name)` / `get_user(name)` /
  `remove_user(name)` / `list_users()` / `list_user_names()`
- New exceptions: `NoSuchUserException`, `UserAlreadyExistsException`

No existing APIs or behaviors are changed.

### How was this patch tested?

28 new unit tests (all passing, `ruff` + `pylint`):

- **DTO tests** 
(`tests/unittests/dto/test_user_dto.py`,
`tests/unittests/dto/responses/test_user_response.py`) — cover builder,
serialization / deserialization roundtrip, equality
- **Client-level mock tests**
(`tests/unittests/client/test_metalake_user_operations.py`) — cover URL,
HTTP method, request body, response parsing, and error propagation for
all five `GravitinoMetalake` methods
- **Error-handler tests** 
(added to `tests/unittests/test_error_handler.py`) — verify the full
error code mapping table for `UserErrorHandler`

Integration tests will be added in the final PR of the split together
with grant/revoke operations, where end-to-end multi-entity behavior
needs to be validated against a real server.

cc @jerryshao — could you help review this when you have time? Thanks!

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

…I and fix UserDTO audit validation (apache#11115)

### What changes were proposed in this pull request?

- Add audit null validation in `UserDTO.Builder.build()` to align with
the Java side
- Add integration tests for User API (`add_user`, `get_user`,
`remove_user`, `list_users`, `list_user_names`)
- Update existing unit tests to provide audit in Builder calls

### Why are the changes needed?

The Java `UserDTO.Builder.build()` validates `audit != null`, but the
Python counterpart does not. Also, PR apache#11058 only added mocked unit
tests for the User API. Integration tests are needed to validate against
a real Gravitino server.

Fix: apache#11114

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

- 8 new integration tests passed against a real Gravitino server with
authorization enabled
- 36 existing unit tests passed

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

apache#11109)

## Summary
This PR adds Group authorization management support to the Gravitino
Python client SDK, following the pattern established in apache#11058 (User
management). It is split from the original monolithic PR apache#10783.

### Changes
- **API**: `Group` interface with `name()` and `roles()` methods
- **DTO**: `GroupDTO` with immutable roles (`tuple[str, ...]`
internally, defensive `list` copy via `roles()`); audit null validation
in Builder
- **Request/Response**: `GroupAddRequest`, `GroupResponse`,
`GroupListResponse`, `GroupNamesListResponse`
- **Error Handler**: `GroupErrorHandler` mapping REST error codes to
`NoSuchGroupException`, `GroupAlreadyExistsException`, etc.
- **Client**: 5 CRUD methods on both `GravitinoMetalake` and
`GravitinoClient` (`add_group`, `remove_group`, `get_group`,
`list_groups`, `list_group_names`)
- **Tests**: Unit tests (33 cases) and integration tests (6 cases)

### Sub-task of
- apache#10782 (Authorization management for Python SDK)

## Related issues
- Closes apache#11094

## Reviewers
@jerryshao

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>

…ata structures (apache#11210)

### What changes were proposed in this pull request?

Add Role CRUD operations and authorization data structures to the Python
client SDK:

- **DTOs**: `PrivilegeDTO`, `SecurableObjectDTO`, `RoleDTO` with JSON
serialization support
- **Role CRUD**: `create_role`, `get_role`, `delete_role`,
`list_role_names` on `GravitinoMetalake` and `GravitinoClient`
- **DTOConverters**: `to/from_privilege_dto` and
`to/from_securable_object_dto` conversion methods
- **Fix**: `GenericPrivilege.__eq__` now checks `isinstance(value,
Privilege)` for `PrivilegeDTO` compatibility
- **Tests**: Unit tests (DTO, response, client delegate, error handler)
and integration tests against a live server

### Why are the changes needed?

This is the Role authorization piece of issue apache#10782. User (apache#11058) and
Group (apache#11094) management are already merged. Role CRUD is a
prerequisite for Grant/Revoke operations, which will follow in a
separate PR.

Fix: apache#11095

### Does this PR introduce _any_ user-facing change?

Yes — new public APIs on `GravitinoClient` and `GravitinoMetalake`:
- `create_role(role_name, properties=None, securable_objects=None)`
- `get_role(role_name)`
- `delete_role(role_name) -> bool`
- `list_role_names() -> list[str]`

### How was this patch tested?

- Unit tests: all passed
- Integration tests: 4 passed against a live Gravitino server with
authorization enabled
- Linting: `ruff check` clean, `pylint` 10/10

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>

…apache#11058)

### What changes were proposed in this pull request?

This PR is split from apache#10783 to make review easier. It focuses on the
**User** part of the authorization model; Group, Role, Privilege,
SecurableObject and grant/revoke operations will follow in subsequent
PRs.

Changes in this PR:

1. **API layer** (`gravitino/api/authorization/`)
   - `User` — user interface with `name()` / `roles()` accessors

2. **DTO layer** (`gravitino/dto/authorization/`)
   - `UserDTO` — immutable DTO with builder pattern, serialization
     and audit info

3. **Request / Response DTOs** (`gravitino/dto/`)
   - `UserAddRequest`
   - `UserResponse` / `UserListResponse` / `UserNamesListResponse`
   - `RemoveResponse` (shared boolean-remove response used across
     authorization operations)

4. **Client layer** (`gravitino/client/gravitino_metalake.py`)
   - Five new public methods on `GravitinoMetalake`:
     `add_user` / `get_user` / `remove_user` / `list_users` /
     `list_user_names`

5. **Exception handling** (`gravitino/exceptions/`)
   - `NoSuchUserException`, `UserAlreadyExistsException`
   - `UserErrorHandler` mapping REST error codes to the above

### Why are the changes needed?

The Python SDK currently has no authorization management capabilities,
while the Java SDK and REST API have full support. This PR starts
bringing the Python SDK to feature parity with the Java SDK, beginning
with User management as the most foundational entity.

Fix: apache#11098

### Does this PR introduce _any_ user-facing change?

Yes. New public API:
- `GravitinoMetalake.add_user(name)` / `get_user(name)` /
  `remove_user(name)` / `list_users()` / `list_user_names()`
- New exceptions: `NoSuchUserException`, `UserAlreadyExistsException`

No existing APIs or behaviors are changed.

### How was this patch tested?

28 new unit tests (all passing, `ruff` + `pylint`):

- **DTO tests** 
(`tests/unittests/dto/test_user_dto.py`,
`tests/unittests/dto/responses/test_user_response.py`) — cover builder,
serialization / deserialization roundtrip, equality
- **Client-level mock tests**
(`tests/unittests/client/test_metalake_user_operations.py`) — cover URL,
HTTP method, request body, response parsing, and error propagation for
all five `GravitinoMetalake` methods
- **Error-handler tests** 
(added to `tests/unittests/test_error_handler.py`) — verify the full
error code mapping table for `UserErrorHandler`

Integration tests will be added in the final PR of the split together
with grant/revoke operations, where end-to-end multi-entity behavior
needs to be validated against a real server.

cc @jerryshao — could you help review this when you have time? Thanks!

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

…I and fix UserDTO audit validation (apache#11115)

### What changes were proposed in this pull request?

- Add audit null validation in `UserDTO.Builder.build()` to align with
the Java side
- Add integration tests for User API (`add_user`, `get_user`,
`remove_user`, `list_users`, `list_user_names`)
- Update existing unit tests to provide audit in Builder calls

### Why are the changes needed?

The Java `UserDTO.Builder.build()` validates `audit != null`, but the
Python counterpart does not. Also, PR apache#11058 only added mocked unit
tests for the User API. Integration tests are needed to validate against
a real Gravitino server.

Fix: apache#11114

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

- 8 new integration tests passed against a real Gravitino server with
authorization enabled
- 36 existing unit tests passed

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
Co-authored-by: Jerry Shao <jerryshao@datastrato.com>

apache#11109)

## Summary
This PR adds Group authorization management support to the Gravitino
Python client SDK, following the pattern established in apache#11058 (User
management). It is split from the original monolithic PR apache#10783.

### Changes
- **API**: `Group` interface with `name()` and `roles()` methods
- **DTO**: `GroupDTO` with immutable roles (`tuple[str, ...]`
internally, defensive `list` copy via `roles()`); audit null validation
in Builder
- **Request/Response**: `GroupAddRequest`, `GroupResponse`,
`GroupListResponse`, `GroupNamesListResponse`
- **Error Handler**: `GroupErrorHandler` mapping REST error codes to
`NoSuchGroupException`, `GroupAlreadyExistsException`, etc.
- **Client**: 5 CRUD methods on both `GravitinoMetalake` and
`GravitinoClient` (`add_group`, `remove_group`, `get_group`,
`list_groups`, `list_group_names`)
- **Tests**: Unit tests (33 cases) and integration tests (6 cases)

### Sub-task of
- apache#10782 (Authorization management for Python SDK)

## Related issues
- Closes apache#11094

## Reviewers
@jerryshao

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>

…ata structures (apache#11210)

### What changes were proposed in this pull request?

Add Role CRUD operations and authorization data structures to the Python
client SDK:

- **DTOs**: `PrivilegeDTO`, `SecurableObjectDTO`, `RoleDTO` with JSON
serialization support
- **Role CRUD**: `create_role`, `get_role`, `delete_role`,
`list_role_names` on `GravitinoMetalake` and `GravitinoClient`
- **DTOConverters**: `to/from_privilege_dto` and
`to/from_securable_object_dto` conversion methods
- **Fix**: `GenericPrivilege.__eq__` now checks `isinstance(value,
Privilege)` for `PrivilegeDTO` compatibility
- **Tests**: Unit tests (DTO, response, client delegate, error handler)
and integration tests against a live server

### Why are the changes needed?

This is the Role authorization piece of issue apache#10782. User (apache#11058) and
Group (apache#11094) management are already merged. Role CRUD is a
prerequisite for Grant/Revoke operations, which will follow in a
separate PR.

Fix: apache#11095

### Does this PR introduce _any_ user-facing change?

Yes — new public APIs on `GravitinoClient` and `GravitinoMetalake`:
- `create_role(role_name, properties=None, securable_objects=None)`
- `get_role(role_name)`
- `delete_role(role_name) -> bool`
- `list_role_names() -> list[str]`

### How was this patch tested?

- Unit tests: all passed
- Integration tests: 4 passed against a live Gravitino server with
authorization enabled
- Linting: `ruff check` clean, `pylint` 10/10

---------

Co-authored-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>