## What changed?
- Previously when creating pointers within a CHASM tree, the pointed-to
component had to already exist within the tree, as the pointer was
resolved immediately. This was cumbersome in some common cases like
setting up an initial tree of CHASM components (such as setting up a
scheduler tree), where ideally, all components would be created and
linked up within the first transaction.
- A new field type, `fieldTypeDeferredPointer`, has been introduced.
This field stores the pointer value directly, and resolves the value to
the path of the component within the tree during `CloseTransaction` (or
fails if the pointer is dangling).
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
- Add CHASM built-in visibility component and task processing logic
## Why?
- Basic chasm visibility work for unblocking Scheduler migration.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## What changed?
- Properly Implement Ref() method and populate all necessary fields
- Refactor ComponentRef and related methods
## Why?
- CHASM workstream
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
CHASM: Add basic `ComponentPointer` support to CHASM component.
## Why?
Part of CHASM workstream. Few things are still pending:
1. `RefC` and `RefD` should return error.
2. Implementation of `RefC` and `RefD` needs to be revisited. It is not
clear if it is possible to implement w/o deserializing entire component
starting from root and all the way down, because `n.value` is needed to
compare with passed argument.
3. Dangling pointers protection is not implemented.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
<!-- Describe what has changed in this PR -->
Remove license header from every file. Because it is really hard to
follow in this PR here is the summary:
1. License header is removed from all `.go` and `.proto` files
:fireworks::fireworks:🎆.
2. `LICENSE` file in the root directory has only Temporal and Uber
copyrights.
3. 5 other `LICENSE` files added to the packages which have copyrights
different from Temporal and Uber: Datadog, Xargin, "Mat Ryer, Tyler
Bunnell and contributors".
4. `license_file` flag is removed from all code generation tools.
5. `copyright_file` flag is removed from `go:generate mockgen`
directive.
6. All copyright related targets are removed from `Makefile`.
7. Updated Temporal copyright year to 2025 everywhere.
## Why?
<!-- Tell your future self why have you made these changes -->
I double checked with legal department that it is not needed to have
license header in every file. One file per repo is enough. I put all
copyrights to the root `LICENSE` file and removed header from all other
files. Also updated tools and `Makefile`.
## What changed?
<!-- Describe what has changed in this PR -->
- Implement Component() method on chasm tree
- Implement chasm Context
## Why?
<!-- Tell your future self why have you made these changes -->
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Added unit test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
- Chasm interface
## Why?
<!-- Tell your future self why have you made these changes -->
- For the new CHASM framework
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
