StacIO._json_dumps requires unused argument

[matthewhanson]

StacIO._json_loads requires a source argument:

https://github.com/stac-utils/pystac/blob/main/pystac/stac_io.py#L89

But it is unused. In StacIO.read_json:

        txt = self.read_text(source, *args, **kwargs)
        return self._json_loads(txt, source)

it reads from source, then passes both txt and source into _read_json

[matthewhanson]

Looks like the source is added it to be in the function sig for overrides, like https://github.com/stac-utils/pystac/blob/main/pystac/stac_io.py#L264

It seems strange that such a low-level function would have an unused argument in most cases. I was trying to use it to just take advantage of orjson and be consistent and would expect it to just get the dict passed in.
On that note, I think this function should really be a classmethod, as it's not reference self at all either....not in the DuplicateKeyReportingMixin either, where it calls only a class staticmethod.

I'm not sure of the best approach here, but I'd suggest:

• remove source entirely from _json_loads
• use a higher level function to override in DuplicateKeyReportingMixin
• make _json_loads a classmethod, or staticmethod

If it ends up making sense to keep the ability to override _json_loads, then:

• source should not be a required positional argument, make it a kwarg
• still consider making _json_loads a classmethod or staticmethod

[duckontheweb]

Having the source parameter in the JSON read methods for signature overrides makes sense, but I can't see a use for including that in the write methods. I think we should change the StacIO._json_dumps signature to:

def _json_dumps(self, json_dict: Dict[str, Any], **kwargs: Any)

That would allow developers overwriting this to add keyword arguments as needed, but keep the general use-case simple.

I think this function should really be a classmethod, as it's not reference self at all either.

I think I would prefer to keep this as an instance method. Since one of the primary uses of this class is as a base class for custom I/O implementations, there is always a chance that someone would want to overwrite these methods with an implementation that needs instance-level information and they would run into typing issues if they tried to overwrite a classmethod with an instance method. It's maybe less likely in the case of this method, but I think it would be best to keep the flexibility.