[meta] Replace http urls with https urls of the respective sites in core

We don't modify vendored code.

@saurabh_jain I don't get why you reverted those changes?

This issue is about making exact those changes.

Replacing all http URLs with https in core.

Yeah, I don't think #5 was about our code having links to third party websites. It was about modifications in assets/vendor, which is vendor code that we directly copy into our repo. Those files should not diverge from the vendor versions.

Should this be handled as a single issue or should it be split into multiple smaller issues ?

IF smaller issues on what criteria they should be split ?

Based on Domain names ? or module components or any other ?

I would suggest let's make it a strictly first time contributor issues to get new contributors familiar with contribution.

Yes, let's re-scope this into small, easier to review issues. Ideally, the scope is by the type of fix which makes it much easier for reviewers. I haven't looked closed enough but it may be possible to have an issue for user facing strings, one for comments, one for tests, and one for production code. I did see there are a lot of changes to .svg files, which could be a separate issue. So, this issue could be the Meta with children. And when, the children are fixed this could be used to fix any stragglers that have crept in to the code base.

Some other thoughts
1. Any ideas on how to prevent 'http:' in the future
2. Are there tests that are specifically testing http that should not be changed?
3. the migrate test fixtures drupal6.php and durpal7.php are not to be changed.

For lack of my 7am brain being able to come up with a clever way to do this in bash, running

<?php
$f = fopen("5278.diff", "r");
$regxp = "/https:\/\/([a-z0-9A-Z\.-]+)[^a-z0-9A-Z\.-]/i";
$matches = [];
$results = [];
while (!feof($f)) {
  $line = fgets($f);
  if (preg_match($regxp, $line, $matches)) {
    $results[$matches[1]] = isset($results[$matches[1]]) ? $results[$matches[1]] + 1 : 1;
  }

}
array_multisort($results, SORT_DESC);
foreach ($results as $name => $count) {
  echo $name . ": " . $count . "\n";
}

on the original MR gives

example.com: 1412
www.w3.org: 747
www.example.com: 136
jsonapi.org: 77
jqueryui.com: 58
jquery.org: 48
www.drupal.org: 40
api.jqueryui.com: 37
drupal.org: 22
www.test.com: 20
wikipedia.org: 18
google.com: 14
docs.jquery.com: 9
www.doctrine-project.org: 8
fonts.fontprovider.com: 8
php.net: 7
www.sqlite.org: 7
en.wikipedia.org: 7
api.drupal.org: 7
www.collegehumor.com: 7
symfony.com: 6

along with ~80 additional domains with < 5 usages

The numbers are a bit off from the actual work between codebase changes and the vendor changes to be undone. Also the xmnls in the svg files should not be changed, https://www.w3.org/2000/svg is an identifier, not a url, and it should not be https. Still probably a good baseline to start with. Having discussed scoping child issues of metas like this several times with @xjm in the recent past, I'm fairly confident we should be doing this by domain for the top domains and then catch the one-offs in a separate issues or issues as it makes sense. These are probably not novice issues (at least not all) as there are many places where this should not be changed at all. Let's start with a child issues for
example.com: 1412
www.w3.org: 747
www.example.com: 136
jsonapi.org: 77
jqueryui.com: 58
jquery.org: 48
www.drupal.org: 40
api.jqueryui.com: 37
drupal.org: 22
www.test.com: 20
<\code>

and go from there. We can also probably standardize on replacing http://example.com with https://www.example.com and http://drupal.org with https://www.drupal.org while we are at it.

@mikelutz, thanks for the script and the numbers. Doing this by URL makes sense to me now.