Add support for OCI registries through ORAS

[isc-dchui]

Introduce support for OCI registries using ORAS.

Mostly uses the ORAS Python client library via embedded Python, but augmented with ObjectScript and REST.

A docker container containing a simple OCI registry (ZOT) has been added to the docker-compose. To test out the containerized zot registry, in IPM configure an ORAS registry with http://oras:5000 as the URL.

It can then be published to and installed from like any other remote registry. Visit http://localhost:5001 to see the registry's UI.

Fixes #581

[isc-kiyer]

@isc-dchui done an initial pass (not very thoroughly). Left some comments/questions

[isc-kiyer]

If we are using embedded python in IPM, does this further limit the earliest IRIS version that IPM can be installed on?
I believe requirements.txt is currently always enforced. We should maybe make this optional so that IPM can still be installed on older versions of IRIS which don't have embedded python with just ORAS support disabled unless embedded python exists.
cc @isc-tleavitt

[isc-dchui]

Thanks for the feedback! Just had a discussion with @isc-tleavitt and it seems one possible approach is allow IRIS versions without embedded python to tolerate a failure to compile requirements.txt and handle run time issues by preventing the creation of ORAS repository definitions. This would also mean avoiding [Language = python ] methods so that the classes compile.

[isc-kiyer]

@isc-shuliu @isc-tleavitt Not a blocker for this PR but what happens behind a firewall with installing python dependencies? Should IPM be packaged with a version of oras as a backup in case the internet is not available to install the latest version?
cc @isc-eneil @isc-jili @isc-jlechtne

[isc-dchui]

@isc-kiyer, @isc-shuliu fixed the majority of the requested changes. The only issue is the backwards compatibility with embedded Python. Unfortunately it looks like removing all [ Language = python ] methods has not proven straightforward. For example, take this snippet of Python code

# library function that returns a dictionary
manifest = client.get_manifest(target)
for key in manifest['annotations']:
	if key == "com.intersystems.ipm.module.v1+xml":
		moduleXML = manifest['annotations'][key]
		# remove whitespace
		return "".join(moduleXML.split())

Unless there's something I'm missing (which could be very possible), iterating through the Python dictionary in Objectscript is incredibly painful.
@isc-tleavitt Thoughts or suggestions?

[isc-kiyer]

@isc-dchui Hmm I checked and embedded python was introduced in 21.2 and the first EM release to include it was 22.1. If we want to say we don't support older versions of IRIS for IPM v1, we could include this embedded python (I am fine with that but would want @isc-tleavitt to confirm). That being said, we need to make sure we don't hit any bugs embedded python may have had in those older versions so would need to test this so am a bit conflicted.

[isc-tleavitt]

In weekly meeting today, https://openexchange.intersystems.com/package/PyHelper came up as an option - specifically ArrayFrompyDict looks useful.

[isc-tleavitt]

Discussed with @isc-shuliu today. Plan is:

• I've polled on DC to see if anyone really wants earlier version compatibility: https://community.intersystems.com/post/anyone-using-ipm-earlier-20221
• @isc-shuliu is going to spend some time kicking the tires on this, then we'll merge to v1-next and possibly take removal [ Language = python ] methods as a follow-up action. This will get ORAS out of a feature branch and into a branch that will also be getting related fixes that HS/TC will need.

[isc-tleavitt]

Looks to me like this is in good shape!

[isc-kiyer]

@isc-shuliu final round of comments!

[isc-eneil]

@isc-shuliu I left a few small comments/questions!