[Rename] Refactored src/{typings,test_helpers,utils} root files (#140)

* [Rename] src/core/test_helpers

* [Rename] src/core/types

* [Rename] src/core/utils

* [Rename] src/core/ docs

Signed-off-by: Mihir Soni <mihirsoni.123@gmail.com>

src/core/CONVENTIONS.md

@@ -21,7 +21,7 @@ Definition of done for a feature:
 - there is no contradiction between client and server API
 - works for OSS version
    - works with and without a `server.basePath` configured
-   - cannot crash the Kibana server when it fails
+   - cannot crash the OpenSearch Dashboards server when it fails
 - works for the commercial version with a license
    - for a logged-in user
    - for anonymous user
@@ -37,11 +37,11 @@ Definition of done for a feature:
 ## Technical Conventions
 ### Plugin Structure
 
-All Kibana plugins built at Elastic should follow the same structure.
+All OpenSearch Dashboards plugins built at Elastic should follow the same structure.
 
 ```
 my_plugin/
-├── kibana.json
+├── opensearch_dashboards.json
 ├── public
 │   ├── applications
 │   │   ├── my_app
@@ -68,7 +68,7 @@ my_plugin/
     ├── index.ts
     └── plugin.ts
 ```
-- [Manifest file](/docs/development/core/server/kibana-plugin-core-server.pluginmanifest.md) should be defined on top level.
+- [Manifest file](/docs/development/core/server/opensearch-dashboards-plugin-core-server.pluginmanifest.md) should be defined on top level.
 - Both `server` and `public` should have an `index.ts` and a `plugin.ts` file:
   - `index.ts` should only contain:
     - The `plugin` export
@@ -293,7 +293,7 @@ For creating and registering a Usage Collector. Collectors should be defined in
 ```ts
 // server/collectors/register.ts
 import { UsageCollectionSetup } from 'src/plugins/usage_collection/server';
-import { CallCluster } from 'src/legacy/core_plugins/elasticsearch';
+import { CallCluster } from 'src/legacy/core_plugins/opensearch';
 
 export function registerMyPluginUsageCollector(usageCollection?: UsageCollectionSetup): void {
   // usageCollection is an optional dependency, so make sure to return if it is not registered.
@@ -306,7 +306,7 @@ export function registerMyPluginUsageCollector(usageCollection?: UsageCollection
     type: MY_USAGE_TYPE,
     fetch: async (callCluster: CallCluster) => {
 
-    // query ES and get some data
+    // query OpenSearch and get some data
     // summarize the data into a model
     // return the modeled object that includes whatever you want to track
 

src/core/README.md

@@ -1,35 +1,35 @@
 # Core
 
-Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.
+Core is a set of systems (frontend, backend etc.) that OpenSearch Dashboards and its plugins are built on top of.
 
 ## Plugin development
 Core Plugin API Documentation:
- - [Core Public API](/docs/development/core/public/kibana-plugin-core-public.md)
- - [Core Server API](/docs/development/core/server/kibana-plugin-core-server.md)
+ - [Core Public API](/docs/development/core/public/opensearch-dashboards-plugin-core-public.md)
+ - [Core Server API](/docs/development/core/server/opensearch-dashboards-plugin-core-server.md)
  - [Conventions for Plugins](./CONVENTIONS.md)
- - [Testing Kibana Plugins](./TESTING.md)
- - [Kibana Platform Plugin API](./docs/developer/architecture/kibana-platform-plugin-api.asciidoc )
+ - [Testing OpenSearch Dashboards Plugins](./TESTING.md)
+ - [OpenSearch Dashboards Platform Plugin API](./docs/developer/architecture/kibana-platform-plugin-api.asciidoc )
 
 Internal Documentation:
  - [Saved Objects Migrations](./server/saved_objects/migrations/README.md)
 
-## Integration with the "legacy" Kibana
+## Integration with the "legacy" OpenSearch Dashboards
 
-Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it.
-Kibana is started using existing "legacy" CLI that bootstraps `core` which in turn creates the "legacy" Kibana server.
-At the moment `core` manages HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server
+Most of the existing core functionality is still spread over "legacy" OpenSearch Dashboards and it will take some time to upgrade it.
+OpenSearch Dashboards is started using existing "legacy" CLI that bootstraps `core` which in turn creates the "legacy" OpenSearch Dashboards server.
+At the moment `core` manages HTTP connections, handles TLS configuration and base path proxy. All requests to OpenSearch Dashboards server
 will hit HTTP server exposed by the `core` first and it will decide whether request can be solely handled by the new 
-platform or request should be proxied to the "legacy" Kibana. This setup allows `core` to gradually introduce any "pre-route"
-processing logic, expose new routes or replace old ones handled by the "legacy" Kibana currently.
+platform or request should be proxied to the "legacy" OpenSearch Dashboards. This setup allows `core` to gradually introduce any "pre-route"
+processing logic, expose new routes or replace old ones handled by the "legacy" OpenSearch Dashboards currently.
 
-Once config has been loaded and some of its parts were validated by the `core` it's passed to the "legacy" Kibana where 
+Once config has been loaded and some of its parts were validated by the `core` it's passed to the "legacy" OpenSearch Dashboards where 
 it will be additionally validated so that we can make config validation stricter with the new config validation system.
 Even though the new validation system provided by the `core` is also based on Joi internally it is complemented with custom 
 rules tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that config values that were previously accepted
-by the "legacy" Kibana may be rejected by the `core` now.
+by the "legacy" OpenSearch Dashboards may be rejected by the `core` now.
 
 Even though `core` has its own logging system it doesn't output log records directly (e.g. to file or terminal), but instead
-forward them to the "legacy" Kibana so that they look the same as the rest of the log records throughout Kibana.
+forward them to the "legacy" OpenSearch Dashboards so that they look the same as the rest of the log records throughout OpenSearch Dashboards.
 
 ## Core API Review
 To provide a stable API for plugin developers, it is important that the Core Public and Server API's are stable and
@@ -39,7 +39,7 @@ process described below. Changes to the API signature which have not been accept
 When changes to the Core API's signatures are made, the following process needs to be followed:
 1. After changes have been made, run `yarn docs:acceptApiChanges` which performs the following:
    - Recompiles all typescript typings files
-   - Updates the API review files `src/core/public/kibana.api.md` and `src/core/server/kibana.api.md`
+   - Updates the API review files `src/core/public/opensearch_dashboards.api.md` and `src/core/server/opensearch_dashboards.api.md`
    - Updates the Core API documentation in `docs/development/core/`
 2. Review and commit the updated API Review files and documentation
 3. Clearly flag any breaking changes in your pull request