Porting network_acls to database generator

[Aryan470]

Fixes #1798

I wrote the generator directives in a new file, cluster/network_acls.go, and changed the internal implementations of the methods in network_acls.go to use the generated functions, maintaining the same function signatures.

To verify this, I ran make update-schema && make && make unit-test && make static-analysis. It passed the unit tests and static analysis on my environment.

This is my first contribution so I would appreciate any guidance on anything I missed. Thanks!

[stgraber]

Error: Failed loading config: Failed to fetch from "networks_acls_config" table: Failed to fetch from "networks_acls_config" table: no such column: networks_acls_config.networkACL_id

Looks like there's an issue with the name of the foreign key here. Should be network_acl_id.

[Aryan470]

I have updated the entity name in the generator directives to be network_acl. I looked at internal/server/db/cluster/config.mapper.go:79 GetConfig, and I think this entity name is in line with what it is expecting given what I read in internal/server/db/cluster/schema.go for networks_acls_config.

[Aryan470]

It seems that now the system tests are all passing, but the entity name being network_acl makes it so we have to name the struct NetworkAcl (lowercase cl) which causes the static analysis to fail. This is why I tried to change the entity name earlier, but then it caused the SQL queries to be wrong.

I think the database generator assumes network_acl -> NetworkAcl because of the PascalCase calls? But when we specify the entity name as NetworkACL it is not going to use network_acl_id when accessing the fields in config table.

[stgraber]

I'm waiting for @masnax to look at the DB generator side of things here to get the names to pass golangci-lint. The database generator has some custom keys to override some of that behavior, but it may also make sense to add a list of abbreviations to generate-database to have it handle such cases.

[masnax]

You should be able to override the computed struct name if you use that as the value given to the -e flag in the generate directives. So replace all of

//generate-database:mapper stmt -e network_acl ...

With

//generate-database:mapper stmt -e NetworkACL ...

and same for methods.

[masnax]

Ah, spoke too soon. It looks like this PR is necessary first.

[stgraber]

I rebased on main to get @masnax's change and renamed to NetworkACL.
Static analysis looks good locally.

Now what's missing is actually nuking db/network_acls.go itself and have the callers of those functions directly hit the cluster functions.

[stgraber]

Right, so that took a bit of effort to sort it all out to a satisfying state.

Basically what I did is that for all the cases where we were only dealing with minimal data manipulations, I just moved the logic from internal/server/db/network_acls.go into the caller. In some cases those callers were doing their own data manipulations so we didn't end up seeing a significant increase in line count/complexity as part of that.

Then for the remaining two which dealt with API structs, I moved them over to the internal/server/db/cluster package and changed their types to match.