Evaluate RLS joins with the owner identity

[egormanga]

Description of Changes

Fix for a bigger issue brought up in #2830 (comment).

Additionally, this seems to allow for some extra query optimizations (see tests).

API and ABI breaking changes

None.

Expected complexity level and risk

2:

While the fix seems pretty straightforward, it somehow affected query optimization logic so it might go a bit deeper than that.

Testing

• A simple setup:

  #[table(name=test, public)]
  pub struct Test {
  	owner_id: Identity,
  }
  
  #[client_visibility_filter]
  const TEST_FILTER: Filter = Filter::Sql("SELECT test.* FROM test JOIN access WHERE access.owner_id == :sender AND access.allowed = true");
  
  #[table(name=access, public)]
  pub struct Access {
  	owner_id: Identity,
  	allowed: bool,
  }
  
  #[client_visibility_filter]
  const ACCESS_FILTER: Filter = Filter::Sql("SELECT * FROM access WHERE false");
  
  #[reducer]
  pub fn test_add(ctx: &ReducerContext) {
  	ctx.db.test().insert(Test {
  		owner_id: ctx.sender,
  	});
  }

  1. call test_add
  2. add an Access
  3. sql SELECT * FROM test;
     Result: [] → [0xIDENTITY]
• A personal project where the issue arose
• Added a test
• Understand why the existing test result changed

[CLAassistant]

All committers have signed the CLA.

[joshua-spacetime]

@egormanga this means the expression will be evaluated as though it were from the owner identity, not the caller identity. And the owner bypasses RLS rules, meaning their access is not restricted. So this would result in non-owner identities gaining access to data they shouldn't.

[egormanga]

I don't think so. According to my testing, this only applies to the RLS rule evaluation, not to the original user query.

I might be wrong, but if I wouldn't get both positive test results for my case and negative for restricted data access (e.g. the access table in my example), I wouldn't've submitted this PR :)