feat: add gres.conf editor to slurmutils

[NucciTheBoss]

This PR adds the gresconfig module for editing gres.conf configuration files on machines. This module is necessary for configuring GPUs in Charmed HPC.

Key things to note

• This editor uses a new approach for defining descriptors for mutating configuration options through data models. Rather than dynamically create descriptors using the generate_descriptors(...) function, they're instead manually defined. Static type checkers such as pyright do not effectively support dynamic attributes without ugly hacks, so here I just created all the descriptors using live templates in PyCharm. Ctrl+J propsd will quickly enter the boilerplate for the descriptors.

  This should make it easier for using a static type checker on code that uses slurmutils without needing to deactivate checks. If we're happy with how it looks here, I will look into applying it to all the other data models within slurmutils.

• Why are all the deleters encapsulated with try: ... except AttributeError: pass ? I realized that if you call del on a data model attribute before setting a key within the internal dictionary associated with the created data model, Python will raise an AttributeError since the key does exist inside the internal dictionary. Since the desired behavior is that the configuration option is unset and not present in the generated configuration file, the AttributeError is silently handled rather than emit a warning message.

[dsloanm]

Looks good! I checked out the branch and created a few test gres.confs without issue. I see GresTypes and Gres have been in slurm.conf for a while so no changes needed there.

For the getters/setters/deleters, my preference would be for dynamic over IDE-generated boilerplate, just to make the code more concise, but I can see your point re: pyright.

[NucciTheBoss]

For the getters/setters/deleters, my preference would be for dynamic over IDE-generated boilerplate, just to make the code more concise, but I can see your point re: pyright.

That's a fair point from the library development perspective; you can only do Ctrl+J propsd so many times before it starts to wear on you, however, I do think that there's trade-offs to both approaches.

Dynamic attributes save you time when developing slurmutils data model objects, but it makes it quite difficult to fully leverage the benefits of static type checkers in downstream projects. For example, pyright "explodes" in the Slurm charms unless we disable reporting missing attributes. We also lose the benefit of tab-completion. While technically it doesn't change anything in the downstream code, it still is pretty nice from the UX perspective that entering something like config. will bring up all the available configuration options.

Explicit attributes take more time to create (and possibly maintain), but it allows us to be serious about static type checking. It's also arguably better to be explicit rather than implicit as there's less ambiguity about what data models can and can't do.