fix: Share resource to use REFERENCE_USAGE instead of USAGE

[joncourt]

Modified the share resource to use REFERENCE_USAGE instead of USAGE on the short lived TEMP db used to allow accounts to be attached to the share where a database isn't already associated. This was causing a conflict during an update action where accounts are modified because a share can be granted usage to only one database - and that is already taken by another database on the share during an update operation.

Note that the USAGE privilege will be automatically added to a share when REFERENCE_USAGE is granted to the first database assigned to the share so the revoke operation must remain. Where USAGE hasn't been granted a revoke operation is not an error so it is safe to leave the revoke in place for the cases where it's needed without a check.

I've also updated the readme with some actions I had to apply to get acceptance tests running in my local fork.

The SKIP_DATABASE_TESTS and SKIP_WAREHOUSE_TESTS variables didn't seem to stop tests that required an enterprise account - so I used a trial enterprise account and updated the readme to say to just use that.

I also had to set the REVIEWDOG_GITHUB_API_TOKEN variable with a token I'd given read/write privileges on the discussion - which I added to the readme.

Accounts still cannot be deleted using the share resource - I suspect that is by design? I did update that but reverted it because I realised it would pick up any manually added accounts and delete them too which scared me, particularly for our 'in use' public listings.

Test Plan

• acceptance tests
• relevant internal/unit tests updated in share_test.go

References

• https://docs.snowflake.com/en/sql-reference/sql/grant-privilege-share.html#usage-notes

[alldoami]

/ok-to-test sha=45eefa8

[github-actions]

Integration tests success for 45eefa8