Version 3

[mullermp]

Issue #, if available:

First of many PRs to address customer issues and modernize the code.

Description of changes:

This PR syncs the internal LambdaRubyRIC package code with the public GitHub. The intent will be for the public gem to be eventually re-imported back internally and used with the runtime.

I also deleted CentOS because I could not get it to work - it's actually just deprecated and the image does not exist anymore. The mirrorlist has been removed.

Makefile test-unit, test-integ, and test-smoke will pass.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mullermp]

@jordan-brough FYI

[mullermp]

I plan to set a higher minimum version of Ruby and do massive code clean ups, but in the interest of doing this in chunks, this change specifically aligns both the internal package and the public package.

@briensea @trivenay FYI - The one file that remains different is the Makefile because of brazil path. Let's talk offline.

[briensea]

Is there a specific reason to use 3.1 over 3.3?

[mullermp]

This was what was internal. My focus here was to do the syncing and do incremental upgrades on top later. I also wanted to discuss a release strategy. Typically ruby gems support multiple versions of ruby like this gem seemed to do. I think for lambdas use case, it may be simpler to release minor versions corresponding to the ruby version and support a singular ruby minor version. E.g. gem version 3.4 supports ruby 3.4 only. This may work for lambda because you deploy a single ruby version runtime using this gem correct?