Summary:
Fix the `find-node.sh` call in `react-native-xcode.sh` script

## Related issue
#32168

## Changelog

[iOS] [Fixed] - Fix for unable to find `find-node.sh` in `react-native-xcode.sh` script

Pull Request resolved: #32227

Test Plan: • Run an Xcode build which uses the `scripts/react-native-xcode.sh` in the JS Bundle build phase.

Reviewed By: TheSavior

Differential Revision: D31022043

Pulled By: GijsWeterings

fbshipit-source-id: 10aafd595c3a3a87c22f385ca4f61756f67e9b9d

Summary:
This PR fixes a few issues with the Appearance API (as noted here #28823).

1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).

2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.

3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

### Fixed

#28823

* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`

Pull Request resolved: #29106

Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)

Reviewed By: hramos

Differential Revision: D31284331

Pulled By: sota000

fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd

Summary:
#29099 introduced a regression where non-rounded borders on Android would render partly outside of the bounds of the view as I reported in #32393. This PR addresses that by rendering the borders completely inside the view like it works on iOS, previous version of RN and for rounded corners.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Fixed] - Fix Android border positioning regression

Pull Request resolved: #32398

Test Plan:
Rendering the following code (as reported in the issue) in the RN Tester app:

```jsx
<View
  style={{
    aspectRatio: 1,
    backgroundColor: 'green',
    borderWidth: 8,
    borderColor: 'black',
    borderStyle: 'dashed',
  }}
/>
```

|Before|After|
|--|--|
|![before](https://user-images.githubusercontent.com/378279/137178113-dd2fea7e-48c8-450b-be3a-92706ef93194.png)|![after](https://user-images.githubusercontent.com/378279/137178140-b5ce7b3d-d455-48a9-a57f-0f3194a65c9a.png)|

Reviewed By: yungsters

Differential Revision: D31623647

Pulled By: lunaleaps

fbshipit-source-id: c38d172ae4a9dc48f800c63258223a59e2f621ed

Summary:
the `LogBoxData.addIgnorePatterns` function shows the wrong code to get a item in `Set`. because every item in `set.entries` looks like `[value, value]`, but not `value`.

while the `addIgnorePatterns` function evalutes two itertaions that is not necessary. So I refacted this function.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[General] [Fixed] - for LogBox checking existingPattern in a wrong way.
[General] [Changed] - addIgnorePatterns runs in one iteration.
[General] [Added] - add a function `getIgnorePatterns` in `LogBoxData.js` for tests or other usecases.

Pull Request resolved: #31977

Test Plan:
test codes in `LogBoxData-test.js`:
````js
it('adding same pattern multiple times', () => {
    expect(LogBoxData.getIgnorePatterns().length).toBe(0);
    LogBoxData.addIgnorePatterns(['abc']);
    expect(LogBoxData.getIgnorePatterns().length).toBe(1);
    LogBoxData.addIgnorePatterns([/abc/]);
    expect(LogBoxData.getIgnorePatterns().length).toBe(2);
    LogBoxData.addIgnorePatterns(['abc']);
    expect(LogBoxData.getIgnorePatterns().length).toBe(2);
    LogBoxData.addIgnorePatterns([/abc/]);
    expect(LogBoxData.getIgnorePatterns().length).toBe(2);
  });

  it('adding duplicated patterns', () => {
    expect(LogBoxData.getIgnorePatterns().length).toBe(0);
    LogBoxData.addIgnorePatterns(['abc', /ab/, /abc/, /abc/, 'abc']);
    expect(LogBoxData.getIgnorePatterns().length).toBe(3);
    LogBoxData.addIgnorePatterns([/ab/, /abc/]);
    expect(LogBoxData.getIgnorePatterns().length).toBe(3);
  });
````

and they have passed

Reviewed By: rickhanlonii

Differential Revision: D30675522

Pulled By: yungsters

fbshipit-source-id: 4a05e0f04a41d06cac416219f1e8e540bf0eea02

#32435)

Summary:
Fixes  #32434: RCTLogBox window is orphaned, covering entire screen.

After this change, the logbox window once again is removed from the screen.

## Changelog

Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[iOS] [Fixed] - 32434

Pull Request resolved: #32435

Test Plan:
1.     Use console.warn to generate a yellow warning message in log box.  Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2.     click the log
3.     tap "dismiss"
4.     try to tap anywhere
5. Use Xcode view debugger to inspect the UI state

## Expected

The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen

Reviewed By: philIip

Differential Revision: D31794242

Pulled By: sshic

fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408

…ing nightly releases (now at 20:00 UTC)

Summary:
Add a new -v or --to-version argument to the bump-oss-version script.

When the bump-oss-version script runs, it will use the version string that is passed in, instead of trying to infer it from the current commit. This fixes a bug in the last nightly release where the bump script used a different version string than what the publish script expected.

Nightlies now run at 20:00 hours UTC.

Changelog: [Internal]

Reviewed By: fkgozali, TheSavior

Differential Revision: D31261829

fbshipit-source-id: a9341f93c3c7bf0379aa3c5e7f345182df70f846

Summary: Changelog: [Internal] - extract logic for parsing version in bump-oss-version and add tests

Reviewed By: cortinico

Differential Revision: D32196238

fbshipit-source-id: 6ea7af3d282eea1d876118f056bca94a151e6182

Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function

Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds

Reviewed By: hramos

Differential Revision: D32196237

fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544

Summary:
Pull Request resolved: #32543

Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version

Context:
* There are two types of tags, git and npm, they are unrelated.

* When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version.

* When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version.

* npm and git's `latest` tag should always point to our most recent stable version

This change:
* Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest"
* If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag
* Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`.
* This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version.

Reviewed By: hramos

Differential Revision: D32196239

fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5

Summary: Changelog: [General][Fixed] Revert changes in Jest preprocessor to fix tests in external projects

Reviewed By: yungsters

Differential Revision: D32250044

fbshipit-source-id: 0ed4c9f7bcfa82349b5c2ec7af2ccda970bbb0ef

Summary:
Renames `Keyboard.removeEventListener` to `Keyboard.removeListener`.

When I implemented the compatibility layer in {D26589441 (035718b)}, I accidentally used the wrong name. Since `Keyboard.removeEventListener` was always deprecated, this removes it completely.

Changelog:
[General][Changed] - Rename deprecated `Keyboard.removeEventListener` to `Keyboard.removeListener`.

Reviewed By: lunaleaps

Differential Revision: D32282743

fbshipit-source-id: 309382af3269f85f781d38367d115a2ce3690efb