Support StringIO object as format of ResourceReader

[abarrak]

Minor improvement to support passing stringio for convenience,
This is mainly because I have a use case to read resources in a plugin, before invocation of ResourceReader module and no need to do the read operation twice.

Specs added and passing:

$ rspec spec/unit/resource_reader_spec.rb
Randomized with seed 29683

  ThreeScaleToolbox::ResourceReader
    #load_resource
      invalid json
        raises error
      valid json
        does not return nil
        is loaded
      valid yaml
        does not return nil
        is loaded
      invalid yaml
        raises error
    #read_content
      from URL
        behaves like content is read
          does not return nil
          is read
      from stdin
        behaves like content is read
          is read
          does not return nil
      from stringio
        behaves like content is read
          does not return nil
          is read
      from folder
        error is raised
      from file
        behaves like content is read
          is read
          does not return nil


Finished in 0.05864 seconds (files took 1.67 seconds to load)
15 examples, 0 failures

Randomized with seed 29683
Coverage report generated for RSpec to ./code/3scale/3scale_toolbox/coverage. 2771 / 6581 LOC (42.11%) covered.

@eguzki @abdennour for your kind review.

[abdennour]

Travis CI is failing

[abarrak]

Travis CI is failing

It's unrelated to this change rspec suite is passing in travis, and for this change as shared above.
The issue in travis seems in setup with missing env. variable?

KeyError:
  key not found: "PROVIDER_KEY"
  # ./spec/shared_contexts.rb:61:in `fetch'
  # ./spec/shared_contexts.rb:61:in `block (2 levels) in <top (required)>'

[eguzki]

The travis CI configuration for the 3scale_toolbox is not prepared for passing tests on PRs coming from forks.

LGTM

I have approved the circleCI integration tests. If they pass, I will merge the PR

[abdennour]

@eguzki if you could migrate to GitHub actions, that we will be better

[eguzki]

Currently, I do not see a good reason to migrate from circleCI to GH ACtions. CirclecI is serving us well.

Travis is a different history. We need specific support of travis for ppc64le and s390x builds. @krishvoor what is you opinion on this?

[abarrak]

Both Travis and CircleCI are stellar CI systems, and no harm in using them.

[krishvoor]

@eguzki No doubt, TravisCI & CircleCI are the best of it's kind, and it works.
However, in the long run, we might have to work our way forward to have "one" solution.

GH Actions today does provide a consolidated solution, however, I will try and get something working soon.

[abdennour]

Thanks for listening!