## Why make this change?

- Closes this issue referenced here
#1423. Additional
issue related to this change
#597
- Cosmos DB currently doesn't support field level authorization, it's
expected that we are not honoring ```operationToColumnMap.Excluded```
and ```operationToColumnMap.Included``` and by introducing field level
auth check into the ```GQLFilterParser``` [recent
update](#1407) results the
issue that we are seeing.
- Cosmos have tests to exercise the filter parser, the reason the tests
didn't catch this issue is because the changes here [added
lines](https://github.com/Azure/data-api-builder/blob/1431ffc8c11bcd80f62d51c0c0fd6f15383b147a/src/Service.Tests/CosmosTests/TestBase.cs#L77-L82)
that's added in this PR [recent
update](#1407), this mocks
up the field auth check to always return true for all Cosmos filter
tests.
- ```CosmosMetadataProvider``` does not translate a field wild card (*)
or list of hardcoded include columns to the list of AllowedFields in the
engine's ```AuthorizationResolver``` currently, but we can add a pass
through to the ```TryGetExposedColumnName``` as suggested so it doesn't
throw a ```NotImplementedException``` when user accidently passed in the
fields settings in the Cosmos configuration file.

## What is this change?

- Address this by skipping the field auth check inside of the
GQLFilterParser when the database type is Cosmos

## How was this tested?

- [ x ] Integration Tests
- [ x ] Unit Tests

## Sample Request(s)

```json
query planets {
  planets (filter: {id: {eq: 1000}}) {
    items {
      id
    }
  }
}
```

## Why make this change?

- Closes this issue referenced here
#1423. Additional
issue related to this change
#597
- Cosmos DB currently doesn't support field level authorization, it's
expected that we are not honoring ```operationToColumnMap.Excluded```
and ```operationToColumnMap.Included``` and by introducing field level
auth check into the ```GQLFilterParser``` [recent
update](#1407) results the
issue that we are seeing.
- Cosmos have tests to exercise the filter parser, the reason the tests
didn't catch this issue is because the changes here [added
lines](https://github.com/Azure/data-api-builder/blob/1431ffc8c11bcd80f62d51c0c0fd6f15383b147a/src/Service.Tests/CosmosTests/TestBase.cs#L77-L82)
that's added in this PR [recent
update](#1407), this mocks
up the field auth check to always return true for all Cosmos filter
tests.
- ```CosmosMetadataProvider``` does not translate a field wild card (*)
or list of hardcoded include columns to the list of AllowedFields in the
engine's ```AuthorizationResolver``` currently, but we can add a pass
through to the ```TryGetExposedColumnName``` as suggested so it doesn't
throw a ```NotImplementedException``` when user accidently passed in the
fields settings in the Cosmos configuration file.

## What is this change?

- Address this by skipping the field auth check inside of the
GQLFilterParser when the database type is Cosmos

## How was this tested?

- [ x ] Integration Tests
- [ x ] Unit Tests

## Sample Request(s)

```json
query planets {
  planets (filter: {id: {eq: 1000}}) {
    items {
      id
    }
  }
}
```